dynamicSQL – EXEC（@SQL）与EXEC SP_EXECUTESQL（@SQL）
在SQL Server使用的存储过程中执行dynamicSQL命令的真实世界的利弊是什么？
EXEC (@SQL) 与
EXEC SP_EXECUTESQL @SQL
？
sp_executesql更有可能促进查询计划的重用。 使用sp_executesql ，参数在调用签名中明确标识。 这篇优秀的文章描述了这个过程 。
经常被引用的关于dynamicsql的许多方面的参考是Erland Sommarskog的必读：“ dynamicSQL的诅咒和祝福 ”。
关于SP_EXECUTESQL的一件大事就是它允许你创build参数化的查询，如果你关心SQL注入的话，这是非常好的。
Microsoft的使用sp_executesql文章build议使用sp_executesql而不是execute语句。
由于此存储过程支持参数replace ，因此sp_executesql比EXECUTE更通用; 而且由于sp_executesql生成更可能被SQL Server重用的执行计划，因此sp_executesql比EXECUTE 更有效 。
所以，拿走： 不要使用execute语句 。 使用sp_executesql 。
现在我总是使用sp_executesql，它实际上只是EXEC的包装器，它处理参数和variables。
但是，在调整对超大型数据库的查询时，尤其是在您将数据跨越多个数据库并使用CONSTRAINT限制索引扫描的情况下，请不要忘记OPTION RECOMPILE。
除非您使用OPTION，否则SQL服务器将尝试为您的查询创build一个“一刀切”的执行计划，并在每次运行时运行完整的索引扫描。
这比search效率低得多，意味着它可能会扫描整个索引，而这些索引被限制在你甚至不想查询的范围内：@
- 声明variables
- 通过你的命令设置它，并添加dynamic部分，如sp的使用参数值（这里@IsMonday和@IsTuesday是sp params）
-
执行命令
declare @sql varchar (100) set @sql ='select * from #td1' if (@IsMonday+@IsTuesday !='') begin set @sql= @sql+' where PickupDay in ('''+@IsMonday+''','''+@IsTuesday+''' )' end exec( @sql)
