我和我的同事有一个关于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缓存可以考虑的where条件的数量是否有限制?如果没有这样的技术限制,有没有在这种情况下可以和应该使用多少条件的最佳实践?
发布于 2010-11-22 02:48:12
如果有人感兴趣的话...
我们通过生成在服务器上执行的动态sql解决了这个问题。这样,只使用了相关的where子句,并且语句相对较短。
发布于 2010-01-21 18:16:35
WHERE子句的数量限制不会成为您的问题。
可能是参数嗅探和糟糕(或不正确)的查询计划缓存。
使用OPTIMIZE FOR可以在一定程度上避免这种情况
显然,WHERE子句越简单越好。
发布于 2010-01-21 18:16:19
SQL Server联机丛书有一个实现限制列表,包括查询方面。This是SQL Server2005的列表。
https://stackoverflow.com/questions/2108315
复制相似问题