SQL数据过滤方法

我有一个存储过程，它接收3个用于动态筛选结果集的参数

create proc MyProc  
@Parameter1 int,  
@Parameter2 int,  
@Paremeter3 int   
as  
select * from My_table  
where  
1 = case when @Parameter1 = 0 then 1 when @Parameter1 = Column1 then 1 else 0 end  
and  
1 = case when @Parameter2 = 0 then 1 when @Parameter2 = Column2 then 1 else 0 end  
and  
1 = case when @Parameter3 = 0 then 1 when @Parameter3 = Column3 then 1 else 0 end  
return 

为每个参数传递的值可以是0（对于所有项）或非零（对于在特定列上匹配的项）

---

我可能有20个以上的参数（显示的示例只有3个）。有没有一种更优雅的方法可以在数据库变大时进行扩展？

我使用的方法与您的想法类似：

select *
from TableA 
where 
    (@Param1 is null or Column1 = @Param1)
    AND (@Param2 is null or Column2 = @Param2)
    AND (@Param3 is null or Column3 = @Param3)

---

它通常是相同的，但我使用空值作为中性值，而不是0。从某种意义上讲，它更灵活，@Param变量的数据类型无关紧要。

我使用的方法与上面列出的一些方法略有不同，我没有注意到任何性能影响。我将使用null并强制它成为参数的默认值，而不是为no filter传递0

当我们为参数提供默认值时，它使它们成为可选的，这有助于在调用过程时提高可读性

create proc myProc
    @Parameter1 int = null,  
    @Parameter2 int = null,  
    @Paremeter3 int = null
AS
select
    *
from 
    TableA
where
    column1 = coalesce(@Parameter1,column1)
    and
    column2 = coalesce(@Parameter2, column2)
    and
    column3 = coalesce(@Parameter3,column3)

---

也就是说，我下次可能会尝试使用动态sql方法，看看是否注意到任何性能差异不幸的是动态sql是性能/稳定性方面的最佳解决方案。虽然所有其他常用的方法（

@param不是或Col=@param

，

合并

，

案例

…）都有效，但它们不可预测且不可靠，每次执行的执行计划可能（也将）有所不同，您可能会发现自己花了很多时间试图弄清楚，为什么您的查询在昨天运行正常时执行得非常糟糕。

请看Gail Shaw在上的博客文章。我对原始问题的评论也适用于此。看一看Gail Shaw在上的博客文章，动态查询是一个不错的选择。性能方面。除非您真正了解您的数据，否则不要使用此方法！！请参阅：并搜索“合并”以了解更多信息。本质上，如果所讨论行中的列的值为NULL，并且@Parameter？为NULL，则在SQL中找不到该行为NULL