别误会我的意思，拐杖是有用的东西，但有些地方仍然拄着拐杖蹒跚而行，很久以前就不应该了。我指的是什么拐杖？？

现在，在一些好心但被误导的人因为我是反拐杖而攻击我之前——我，当然，认识到他们的必要性……在某个时间点。但当你摔断一条腿时，关键是你去看医生，把它修好，然后只使用拐杖直到它痊愈。断腿后你不做的事就是挖出一双拐杖，在你的余生中使用它们，而从来没有修好你的腿。这是很不自然的。

然而，有些地方却把上面的东西放在原地……好几年。好几年的痛苦不必要的，因为上面两个都指出进程缓存的大小过小。

那么我们如何正确地调整它的大小？？

首先，您必须了解最大的消费者。现在还不要使用"存储过程（和触发器）"……例如，大多数SAP Business Suite系统都运行有多GB的过程缓存，而且找不到存储过程。如果您查看monprocedurecachemuleusage，您将看到有近30种不同的过程缓存分配器，包括：

其中，最常见的使用者通常是：

有时还有一些其他的使用者，例如

我认为对依赖上述拐杖的客户贡献最大的两个罪魁祸首是严重低估了优化器+执行和语句缓存的过程缓存需求，我认为后者往往是直接造成的，对于前者，让我们先花点时间。

无论是简单的"select*from table"还是复杂的过程，每个查询都使用过程缓存。每一个查询。习惯它。当第一次收到查询并解析SQL时，它就开始了。谢天谢地，这往往没有那么多——只有几页进程缓存。然后我们就开始优化了……哎哟！！这是一个过程缓存的大量消耗者。对于一个简单的"select*from table"，典型的查询优化计划可以从几个低10的KB运行到多个10的MB。对于使用文本值的简单插入、更新或删除也是如此。但是，一旦连接开始，这会很快跳到~200KB。更复杂的查询，如大型联接/嵌套子查询，很容易消耗几MB的过程缓存。

但是请稍候。记住我们是如何得到这个计划的。首先，优化器必须制定一系列"工作计划"作为可能的替代方案。每个已制定的计划都保存在内存中，直到最终的成本计算。工作计划的数量取决于所涉及的表的数量以及where子句中的索引和谓词的数量，但很容易达到10-20。因此，一个查询优化可以在优化过程中使用2-4MB的过程缓存，然后在选择最终计划后降到200KB。

但是我们可以尚未完成。熟悉16sp02编译查询功能的人都知道，一旦选择了查询优化计划，它就不是终点。不，查询执行引擎需要开发一个执行计划，说明它将如何执行查询计划中的物理运算符。例如，如果选择了基于哈希的分组，它需要创建散列桶（散列桶的数量取决于估计），平销返利，等等。净结果可能是200KB的查询计划需要另一个200KB的过程缓存来执行计划。这就是为什么如果你非常注意monProcedureCacheModuleUsage，优化器和执行经常消耗过程缓存的原因。

这就是原因对于具有2-3路连接和几个谓词的基本查询，

现在，以6000行存储过程为例，它可能包含几百个这样的过程。是的。现在我们讨论的是10，如果不是100MB的进程缓存的话。但是通常，大多数开发良好的进程需要2MB。记住，这只是一个副本。每次并发执行，都会加载另一个计划副本。当然，记住–我们加载的只是过程优化计划–我们仍然需要每个语句的执行计划。

我们如何使用它来调整大小？答案很简单——您的系统经常遇到多少并发查询？如果你不确定的话，一个很好的估计就是把你运行的引擎数乘以10，因此，在一个30引擎的系统上，任何时间点都可能有300个查询处于活动状态。如果我们认为每个并发查询可能需要大约2MB的过程缓存，这是一个非常宽松的估计，那么我们说的是，仅在查询优化和执行中就需要大约600MB的过程缓存，这是不太可能的。我们还知道，可能需要500MB的过程缓存来容纳250个正常存储的过程。语句缓存中的每一条语句都需要大约100KB的内存，而该语句的每一个计划也需要内存…..哦…..数学…这只会伤脑筋。

更好的方法是只考虑并发活动会话的数量。现在，如果您是使用10000个连接运行的商店类型，其中大多数连接在任何时间点都处于空闲状态，那么您可能希望定期开始监视monProcess，然后对收集的数据运行查询，类似于：

select SampleTime，count（*）

from monProcess\u hist

where WaitEventID！=250

按样本分组时间

按2描述排序

对于grins，假设答案是1000。现在我们需要知道平均有多少在运行存储过程而不是执行查询。我们需要做的就是在上面的查询中添加一个LineNumber>1的where子句（是的–一个批可以有多行…，但是批处理/存储的proc–当涉及到proc cache以进行优化时几乎是一样的事情）。同样，淘客社区，假设答案是100（很好的10%）。