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