这很有效,我们获得了许多非常有见地的统计数据.很明显,这不像运行探查器跟踪那样准确,因为您不知道sql Server何时决定放弃执行计划.
SELECT TOP 30 a.Id FROM Posts a JOIN Posts q ON q.Id = a.ParentId JOIN PostTags pt ON q.Id = pt.PostId WHERE a.PostTypeId = 2 AND a.DeletionDate IS NULL AND a.CommunityOwnedDate IS NULL AND a.CreationDate > @date AND LEN(a.Body) > 300 AND pt.Tag = @tag AND a.score > 0 ORDER BY a.score DESC
问题是理想的计划实际上取决于所选的日期(理想计划的屏幕截图):
但是如果错误的计划被缓存,当日期范围很大时它会完全窒息:(注意大胖线)
为了克服这个问题,我们建议使用OPTION(OPTIMIZE FOR UNKNowN)或OPTION(RECOMPILE)
对未知的优化导致稍微更好的计划,这远非最佳.在sys.dm_exec_query_stats中跟踪执行.
RECOMPILE会导致选择最佳计划,但不会在sys.dm_exec_query_stats中跟踪执行计数和统计信息.
我们可以使用另一个DMV来跟踪OPTION(RECOMPILE)查询的统计数据吗?
这种行为是按设计的吗?
还有另一种方法可以在sys.dm_exec_query_stats中跟踪统计数据的同时进行重新编译吗?
解决方法
在你的情况下是非常简单的,只需使用良好的查询计划句柄调用sp_create_plan_guide_from_handle
:
You can use this stored procedure to ensure the query optimizer always uses a specific query plan for a specified query.
原文地址:https://www.jb51.cc/mssql/80925.html
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。