dynamicSQL – EXEC（@SQL）与EXEC SP_EXECUTESQL（@SQL）

在SQL Server使用的存储过程中执行dynamicSQL命令的真实世界的利弊是什么？

EXEC (@SQL) 

与

 EXEC SP_EXECUTESQL @SQL 

？

Answer 1

sp_executesql更有可能促进查询计划的重用。 使用sp_executesql ，参数在调用签名中明确标识。 这篇优秀的文章描述了这个过程 。

经常被引用的关于dynamicsql的许多方面的参考是Erland Sommarskog的必读：“ dynamicSQL的诅咒和祝福 ”。

Answer 2

关于SP_EXECUTESQL的一件大事就是它允许你创build参数化的查询，如果你关心SQL注入的话，这是非常好的。

Answer 3

Microsoft的使用sp_executesql文章build议使用sp_executesql而不是execute语句。

由于此存储过程支持参数replace ，因此sp_executesql比EXECUTE更通用; 而且由于sp_executesql生成更可能被SQL Server重用的执行计划，因此sp_executesql比EXECUTE 更有效 。

所以，拿走： 不要使用execute语句 。 使用sp_executesql 。

Answer 4

现在我总是使用sp_executesql，它实际上只是EXEC的包装器，它处理参数和variables。

但是，在调整对超大型数据库的查询时，尤其是在您将数据跨越多个数据库并使用CONSTRAINT限制索引扫描的情况下，请不要忘记OPTION RECOMPILE。

除非您使用OPTION，否则SQL服务器将尝试为您的查询创build一个“一刀切”的执行计划，并在每次运行时运行完整的索引扫描。

这比search效率低得多，意味着它可能会扫描整个索引，而这些索引被限制在你甚至不想查询的范围内：@

Answer 5

1. 声明variables
2. 通过你的命令设置它，并添加dynamic部分，如sp的使用参数值（这里@IsMonday和@IsTuesday是sp params）

3. 执行命令

    declare @sql varchar (100) set @sql ='select * from #td1' if (@IsMonday+@IsTuesday !='') begin set @sql= @sql+' where PickupDay in ('''+@IsMonday+''','''+@IsTuesday+''' )' end exec( @sql)