假设您有一个存储过程,它需要一个可选参数.您希望在SQL查询中使用此可选参数.通常这就是我看到它完成的方式:
SELECT * FROM dbo.MyTableName t1
WHERE t1.ThisField = 'test'
AND (@MyOptionalParam IS NULL OR t1.MyField = @MyOptionalParam)
Run Code Online (Sandbox Code Playgroud)
这似乎运行良好,但如果您使用STATISTICS IO ON运行查询,则会导致大量逻辑读取.我也试过以下变种:
SELECT * FROM dbo.MyTableName t1
WHERE t1.ThisField = 'test'
AND t1.MyField = CASE WHEN @MyOptionalParam IS NULL THEN t1.MyField ELSE @MyOptionalParam END
Run Code Online (Sandbox Code Playgroud)
它产生相同数量的高读数.如果我们将SQL转换为字符串,然后在其上调用sp_ExecuteSQL,则读取几乎为零:
DECLARE @sql nvarchar(max)
SELECT @sql = 'SELECT * FROM dbo.MyTableName t1
WHERE t1.ThisField = ''test'''
IF @MyOptionalParam IS NOT NULL
BEGIN
SELECT @sql = @sql + ' AND t1.MyField = @MyOptionalParam '
END
EXECUTE sp_ExecuteSQL @sql, N'@MyOptionalParam', @MyOptionalParam
Run Code Online (Sandbox Code Playgroud)
我疯了吗?为什么选择哪些条款如此难以正确?
更新:我基本上问是否有办法将标准语法保留在存储过程中并获得低逻辑读取,如sp_ExecuteSql方法.构建一个字符串对我来说似乎是完全疯狂的...更不用说它使得维护,调试,可视化变得更加困难.
您在前两个 SQL 语句上使用“OR”子句(隐式和显式)。最后一个是“AND”标准。“OR”总是比“AND”标准更昂贵。不,你没有疯,应该是预料之中的。
| 归档时间: |
|
| 查看次数: |
8961 次 |
| 最近记录: |