SQL Server - 执行直接查询与使用 sp_executesql 执行
Posted
技术标签:
【中文标题】SQL Server - 执行直接查询与使用 sp_executesql 执行【英文标题】:SQL Server - executing direct query vs. executing with sp_executesql 【发布时间】:2015-02-26 07:36:03 【问题描述】:我正在检查一些 ORM 和 Micro-ORM 的行为,并检查它们如何生成发送到数据库 (SQL Server) 的查询。
我注意到的是两种主要的执行方法:
直接执行查询:
select * from mytable
insert into mytable(val1, val2) values (@val1, @val2)
或者像这样的用户 sp_executesql:
exec sp_executesql N'INSERT INTO mytable(val1, val2) VALUES (@p0, @p1)',N'@p0 int,@p1 nvarchar(4000),@p0=1,@p1=NULL
这两种方法有什么区别?哪个更快?它会影响执行计划吗?
【问题讨论】:
“哪个更快” - 你是否真的认为如果两者之间存在可测量的差异,即总是有一个更快的和一个较慢的,我们就不会全部改用更快的? @Damien_The_Unbeliever 那么为什么要使用另一个呢?可能会对执行计划产生影响。 猜测:在 SQL Server 2005 流行之前编写的 ORM 使用 sp_executesql 来重用查询计划(在 SQL Server 2005 之前,“原始”查询无法重用执行计划)。 【参考方案1】:如果您使用 sp_executesql 的参数(如上面的示例)并且语句的文本在执行之间没有更改,则为第一次执行生成的执行计划可能会用于后续执行。因此,它可能与标准语句的多次执行一样高效(如在您的第一个代码示例中)。
但是sp_executesql语句的内容是作为独立于调用sp_executesql批处理的执行计划的执行计划编译和执行的,所以这样对执行计划有影响。
sp_executesql 存储过程与标准直接语句的主要区别在于前者可用于执行动态创建的语句。
【讨论】:
以上是关于SQL Server - 执行直接查询与使用 sp_executesql 执行的主要内容,如果未能解决你的问题,请参考以下文章
SQL Server-聚焦sp_executesql执行动态SQL查询性能真的比exec好?
SQL Server 日常维护--查询当前正在执行的语句死锁堵塞
SQL Server 中 EXEC 与 SP_EXECUTESQL 的区别