将查询计划按语句拆分以提高可重用性会更好吗？

从我对查询计划如何通过查询进行编译，存储和检索的有限知识中，我了解到多语句查询或存储过程将生成其查询计划，该查询计划将存储在查询计划缓存中，以供查询在将来的执行中使用。

我认为此计划是使用查询哈希从查询计划缓存中检索的，这意味着如果编辑并执行查询，哈希将有所不同，并且会生成新计划，因为在查询计划缓存中找不到匹配的哈希。

我的问题是：如果用户执行多语句查询中的语句之一的语句，是否可以将缓存中已存在的查询计划的相关部分用于多语句查询？我希望答案是否定的，因为哈希值显然不匹配，但是对多语句查询中的每个语句进行哈希处理会更好些，以便用户在查询中运行单个语句可以使用它们吗？

我希望有一些我没有考虑到的复杂因素（而这正是我真正想知道的），但似乎我们可以在许多查询计划中存储相同的“语句计划”，从而占用更多空间并占用更多时间CPU和生成时间。

可能只是显示我的无知。

如果用户执行的语句是多语句查询中的语句之一，是否可以将缓存中已存在的查询计划的相关部分用于多语句查询？

否。SQLServer中计划重用的基本单位是批处理。

在多语句查询中对每个语句进行散列是否会更好，以便运行查询中单个语句的用户可以使用它们？

针对高级计划重用进行了优化的系统会将通用代码（以适当的粒度）放置在SQL Server上的可重用对象（例如过程，函数，触发器）中。它还将显式参数化任何应用程序生成的或客户端代码。为了最大程度地重用计划，这些生成的批次应仅在参数值上有所不同。

我希望有一些我没有考虑到的并发症

听起来您好像在问为什么 SQL Server设计为在批处理级别而不是语句级别缓存和重用。我怀疑除原始设计师之外的任何人都可以权威地回答这个问题。无论如何，在我看来，批处理是使用的自然粒度，因为它是相对独立的自然工作单元，并且代表了实现复杂性和计划重用概率之间的合理权衡。

有一些事情使批处理不是完全独立的（例如，跨存储过程边界创建和引用的本地临时表）。这些异常降低了正交性，并且多年来与意外的“设计使然”行为和错误相关联。