Answers:
让我总结一下（并四舍五入！）电子表格中的重要数据点：
Total Use Count 1
--------------------------------------- -----------------------
Total Plans Total MBs Avg Use Count Total Plans Total MBs
----------- --------- ------------- ----------- ---------
Adhoc 55,987 3,054 3 38,314 2,036
Proc 709 1,502 1,549 135 527因此，第一行显示了不良内容，约占计划缓存的2/3（几乎只使用过一次的内容，还有一些非常小的例外）。您需要尝试摆脱这些问题。第二行显示了好东西。这些是您想要在计划缓存中使用的东西（重复使用率很高的计划）。其余数据在很大程度上与恕我直言无关。但是，还有一点：您说访问仅通过存储过程进行，但是如果那些过程使用动态SQL，则这些语句将作为AdHoc计划而不是Proc计划进行缓存。
在2008年或以后，我要说的是打开电源，optimize for ad hoc workloads然后继续进行下一个问题-这将使您的一次性使用计划当前占用的MB数量几乎减少为零。不幸的是，在2005年，除了重构这些存储过程以使用语句级OPTION (RECOMPILE)和/或更少/没有动态SQL或在数据库级启用强制参数化之外，您的选择非常有限-试图从中获得更好的计划重用性通过将文字视为用于计划匹配的参数来进行类似的查询。我什至不愿提及计划指南，因为它们不适合胆小，而且-正如我稍后在此答案中讨论的那样-除非您知道计划缓存绝对是性能的来源，否则我不确定是否值得走这条路问题。
我@@VERSION之所以问是因为，在SP2之前，可分配给计划缓存的内存量算法相对松散。从SP2开始，他们将其收紧了很多（该变化已在本文章和本文章中得到了记录和解释）。就您而言，计划缓存相对较满，因此缓存未命中也就不足为奇了。26 GB = 5.8 GB的上限；我在电子表格中看到了约4.5 GB，但此处可能存在一些我不知道的计算或配置差异。
这篇MSDN文章讨论了optimize for ad hoc workloads2008年添加的服务器设置，并提到了跟踪标志8032，它将允许您为缓存分配更多的内存（大概是在服务器级别没有设置此设置的情况下，我现在建议所有我们的客户，或者至少有99％的客户不再使用2005年的产品）。我从未在2005 SP3或SP4上测试过此跟踪标志，并且说实话甚至不确定它何时引入。我还不知道它是否会解决您的问题或只是将其转移，因为我认为即使您为缓存分配了更多的RAM百分比，由于内存的性质，您仍然会填充它并有很多缓存未命中您的存储过程。
或者，当然，如果甚至还有要解决的问题，则直接与计划缓存有关。仅仅因为您的缓存命中率不如您预期的那么高并不意味着它会导致您的问题，当然，相反的是，即使在100％的缓存命中率下，鉴于如此之多，这似乎也不现实您的计划是一次性的并且是临时的-您的用户可能仍会遭受完全由其他原因引起的性能问题。
我的建议是寻找比计划缓存命中率更好的吸烟枪。详细了解用户的性能投诉。所有查询总是慢吗？某些查询？每天/每周/营业周期的某些时间？仅报告查询速度慢吗？请认真阅读这份关于SQL Server最佳实践的冗长而冗长的文档，尤其是有关等待和队列的部分，它可以帮助您制定一种逻辑方法来识别，诊断和解决性能问题。使仪表板上的某个数字看起来更好-您甚至不知道直接导致该问题的数字-可能会非常令人满意，但是如果它不能解决用户的性能问题，那么它并没有真正吸引您任何地方。
这些在阅读编译/重新编译和计划缓存重用方面也可能很有用。其中一些专注于2008年（尤其是那些有关临时工作负载设置的信息），但是许多信息仍对2005年有用，并且/或者可以更好地理解升级的好处（提示，提示）。