Jam*_*son 11 sql-server execution-plan plan-cache
根据我对查询如何编译、存储和检索查询计划的有限了解，我了解多语句查询或存储过程将生成它的查询计划，该查询计划将存储在查询计划缓存中，以供查询在未来执行中使用。
我认为这个计划是通过查询哈希从查询计划缓存中检索的，这意味着如果查询被编辑和执行，哈希是不同的，并且会生成一个新计划，因为在查询计划缓存中找不到匹配的哈希。
我的问题是：如果用户执行的语句是多语句查询中的语句之一，它是否可以将缓存中已有的查询计划的相关部分用于多语句查询？我希望答案是否定的，因为哈希值显然不匹配，但是在多语句查询中对每个语句进行哈希处理是否更好，以便用户可以从查询中运行单个语句来使用它们？
我希望有一些我没有考虑到的并发症（我真的很想知道这些），但似乎我们可以在许多查询计划中存储相同的“语句计划”，占用更多空间和更多CPU 和生成时间。
可能只是显示我的无知。
Pau*_*ite 11
如果用户执行的语句是多语句查询中的语句之一，它是否可以使用缓存中已有的查询计划的相关部分进行多语句查询？
否。SQL Server 中计划重用的基本单位是批处理。
对多语句查询中的每个语句进行散列是否更好，以便用户可以从查询中运行单个语句？
为高水平计划重用而调整的系统会将公共代码（以合适的粒度）放置在 SQL Server 上的可重用对象（例如过程、函数、触发器）中。它还将显式参数化任何应用程序生成的或客户端代码。为了最大限度地重用计划，这些生成的批次应该仅在参数值上有所不同。
我希望有一些我没有考虑到的并发症
听起来您在问为什么SQL Server 被设计为在批处理级别而不是在语句级别缓存和重用。我怀疑除了原始设计师之外的任何人都可以权威地回答这个问题。无论如何，在我看来，批处理是一种自然的使用粒度，因为它是相对独立的自然工作单元，代表了实现复杂性和计划重用概率之间的合理权衡。
有一些事情使批处理不完全自包含（例如，跨存储过程边界创建和引用的本地临时表）。这些异常减少了正交性，并且多年来一直与意外的“设计”行为和错误相关联。