在SQL中处理’可

假设您有一个存储进程,它必要一个可选参数.您但愿在SQL查询中行使此可选参数.凡是这就是我看到它完成的方法：

SELECT * FROM dbo.MyTableName t1
WHERE t1.ThisField = 'test'
AND (@MyOptionalParam IS NULL OR t1.MyField = @MyOptionalParam)

这好像运行精采,但假如您行使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

而且它发生沟通数目的高读数.假如我们将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

我疯了吗？为什么选择哪些条款云云难以正确？

更新：我根基上问是否有步伐将尺度语法保存在存储进程中并得到低逻辑读取,如sp_ExecuteSql要领.构建一个字符串对我来说好像完全疯了……更不消说它使得维护,调试,可视化变得越发坚苦.

办理要领

If we convert the SQL to a string,then call sp_ExecuteSQL on it,the reads are almost nil…

>由于您的查询不再评估OR,由于您可以看到杀死sargability
>行使sp_executesql时缓存查询打算; SQL Server不必举办硬理会……

优越资源：The Curse & Blessing of Dynamic SQL

只要您行使参数化查询,就应该从SQL Injection attacks开始安详.

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!