the*_*ony 2 performance sql-server execution-plan
在调查性能问题时，一位同事建议运行 DBCC FREEPROCCACHE 来清除计划缓存。在注意到重启后性能有所提高后，他得出了这个结论。
这感觉像是一种相当快速和肮脏的方法 - 有没有更确定、更明确的方法来确定清除计划缓存是否是最好的方法？做出这个决定的错误可能会导致性能问题。
如果这个问题太模糊，请道歉:)
谢谢！
清除计划缓存从来都不是一个好主意。然后你从一个冷缓存开始，你会看到性能下降，因为 SQL Server 必须从那一刻开始编译所有内容，直到计划被缓存以供重用。
在注意到重启后性能有所提高后，他得出了这个结论。
通常，当我看到 DBA 重新启动、重新启动服务和/或清除过程缓存时，这会给“修复”带来真正误导性的感觉。有时，性能不佳可能是由于执行计划选择不当造成的。通过执行我上面提到的三种方法中的任何一种来获取空缓存，您只是在强迫 SQL Server 手动编译所有内容。有时（尽管并非总是如此）之后的第一个查询是典型的工作负载，并且对于典型的工作负载似乎具有更好的性能.... 这一切都源于错误的参数嗅探。
参数嗅探是一件好事。但是，如果进入 SQL Server 的第一个查询使用设置为“哥斯达黎加”的参数，则 SQL Server 将使用该参数值进行编译并为该参数值制定最佳计划。但是，如果 99.9% 的工作负载使用设置为“美国”的参数，那么 99.9% 的工作负载将重用“哥斯达黎加”生成的计划。
快进并清除缓存（请不要清除缓存，我只是以此为例）。现在你有了一个冷缓存，接下来的查询使用参数“美国”，瞧！SQL Server 使用该参数值进行编译，现在 99.9% 的工作负载正在使用最佳计划。
我想说的DBCC FREEPROCCACHE是，就像使用推土机铲走人行道上的雪一样。您真的应该找出性能不佳的地方以及导致它的原因。然后，如果是特定查询给您带来问题，并且您将其缩小到选择不当的计划，则有许多潜在的途径可以绕过错误的参数嗅探（OPTIMIZE FOR提示、重新编译和其他一些）。