sql-server – sys.dm_exec_query_stats与重新编译的交互

这很有效,我们获得了许多非常有见地的统计数据.很明显,这不像运行探查器跟踪那样准确,因为您不知道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_executesql执行参数化查询

解决方法

在你的情况下是非常简单的,只需使用良好的查询计划句柄调用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.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!