Question

我和我的同事们对SQL Server 2008查询长度和SQL Server优化程序有疑问。

我们计划生成一些可能包含大量参数的存储过程。在我们的存储过程中，我们只需从连接其他表的表中选择一些值。

我们的存储过程将如下所示

CREATE PROCEDURE QueryTable
@Parameter001 nvarchar(20),
@Parameter002 int,
@Parameter003 datetime,
@Parameter004 decimal(11,2),
@Parameter005 date,
@Parameter006 varchar(150),
@Parameter007 int,
@Parameter008 decimal(5,2),
@Parameter009 nvarchar(10),
@Parameter010 nvarchar(200),
@Parameter011 nvarchar(50) --,
--...and so on, there are probably 50 to 100 parameters here

AS
BEGIN
SET NOCOUNT ON;

SELECT ID, COL01, COL02, COL03, COL04, COL05 from TestTable T
LEFT JOIN AnotherTable A On T.SomeColomn = A.SomeColumn
LEFT JOIN AThirdTable ATT On A.ThirdTableID = ATT.Id
--and so on, probably 5-10 Tables joined here
WHERE 
      T.Col02 = @Parameter001 AND
      T.Col05 = @Parameter004 AND
      ATT.SomeColumnContainingData = @Parameter027
      A.AnotherID = @Parameter050
      --probably 50 to 100 conditions here (Number of conditions equals number of parameters)
END
GO

我们的问题：查询优化器和SQL Server缓存可以考虑的条件数量是否有限制？如果没有这样的技术限制，是否有最佳做法可以并且应该在这种情况下使用多少条件？

Answer 1

WHERE子句数量的限制不会成为您的问题。

缓存的参数嗅探和差（或不正确）查询计划可能是。

使用OPTIMIZE FOR

可以避免这种情况

显然，你可以制作WHERE子句越复杂越好。

Answer 2

SQL Server联机丛书有一个实施限制列表，包括查询方面。 This是SQL Server 2005的列表。

Answer 3

如果有人有兴趣......

我们通过生成在服务器上执行的动态sql解决了这个问题。这样只使用相关的where子句，语句相对较短。

存储过程中where子句的最大数量

3 个答案: