Sql server 使用sp_executesql的非最优执行计划

对于同一个查询，使用

sp\u executesql

方式执行此select时，使用某些参数的sql select语句的性能很慢。执行此select时所需的时间是内联方式的两倍

问题在于，在sp_中，执行方式sql server没有使用最佳执行计划。尽管计划不同，但在这两种情况下，表的索引似乎都得到了正确的使用。我真的不明白为什么表现如此不同

我的原始查询更复杂，但为了弄清楚发生了什么，我将原始查询简化为一个包含3个表和2个联接的select。主要的区别是在optimal中使用哈希匹配，我真的不知道这是什么意思，但这是我能看到的唯一区别

最佳计划（哈希匹配，超过3秒）

错误的计划（没有哈希匹配，索引与上面相同，超过12秒）

我认为我的问题不是“参数嗅探”，在我的例子中，对于所有不同的参数值，查询总是很慢，因为执行计划总是不正确的

选项（重新编译）

不起作用，

sp\u executesql

运行缓慢，内联方式需要更多时间（因为查询总是编译执行计划）

表的统计数据已更新

我不得不使用

sp_executesql

方式，因为reporting services似乎封装了

sp_executesql

中的select调用

有人知道为什么sp_executesql生成与内联查询不同（错误）的执行计划吗

---

编辑：查询没有使用相同的索引我想，因为执行树不一样，sqlserver可以随心所欲地使用索引，所以您可以找到新的执行计划来强制使用相同的索引，在慢速查询中，性能现在甚至最差，从12秒到超过15分钟（我已取消）。我真的不想以更快的速度运行这个特定的查询，因为我说这不是我正在处理的真正的查询，我想弄清楚的是为什么内联查询和sp_executesql-query之间的执行计划如此不同

sp_executesql

中有什么神奇的选项可以正常工作吗？：）

最佳的

慢

---

我的理解是，sp_executesql在第一次执行后保留一个缓存的计划。后续查询可能使用了错误的缓存计划。您可以使用以下命令清除整个SQL Server过程缓存

    DBCC FREEPROCCACHE

---

如果您不提供任何代码、索引或执行计划，那么回答您的问题将非常困难。这可能吗？我已经附上了执行计划，thanksIt没有使用相同的索引：1使用IDX_EndDate_Start…，2使用EDX_SiteId_EndDate…你是对的，索引是不同的，我想因为执行树不同，我有强制（使用index（））要同时选择“使用相同的索引”和“慢速查询”，现在的速度甚至比以前慢，从12秒到15分钟多（我已取消…）。我已经编辑了我的帖子，添加了新的screenshotsComment而不是answer，因为我无法判断这是否是问题所在，因为您没有提供查询的文本或第一次执行的参数值。sp_executesql将缓存一个计划，该计划在很大程度上取决于第一次执行时的参数值。本文可能有助于：