将大型 sql 脚本分成较小的批次有好处吗？

Question

我正在编写 500 行的大而粗糙的 sql 脚本。目前大致是这样组织的。

-- Declare and set a couple of dozen variables that will be used in the script
-- Do lots of deletes, inserts, and updates

目前这一切都是在一个批次中完成的。原因是许多操作依赖于公共变量，而变量不会跨越GO 边界。将这样的脚本分成更小的批次是否有好处，即使这意味着在每个批次中重复地重新声明和重新设置一些变量？

-- Declare a few variables
-- Run the delete, update, and insert operations that rely on those variables
-- GO

-- Declare a few variables, some new and some the same as from the previous batch
-- Run the delete, update, and insert operations...
-- GO

-- Rinse and repeat about a dozen times

获取变量的值并不昂贵，通常将它们设置为文字或 selecting 从只有 10 行的表中的结果。

每次删除、更新和插入操作都在大约 100 万到 500 万行的集合上进行。

是否存在理论上的内存、存储（用于日志文件）和/或性能改进，可以通过将其分成多个批次来获得，并且这将超过重新声明和重新设置一些的丑陋和烦恼变量多次？

在这种情况下，有哪些资源可以详细了解批次？我知道在某些情况下需要批处理，例如在对新表/列进行操作之前创建或更新表。 this 问题的答案表明，当使用较小的批次时，日志文件的大小可能会有一些好处。我无法找到关于使用小批量的可能方案和性能优势的确切信息来源。

谢谢

Answer 1

是的，你应该这样做。将其拆分为逻辑块。

例如：

 exec base_data
     can call exec base_data_address
     can call exec base_data_name
     can call exec base_data_date

• 易于阅读。
• 易于维护和调试。
• 易于重用带有参数的过程。
• 易于控制交易流程。
• 易于错误处理。
• 轻松添加新块。

如果您必须发送大量变量，则似乎有问题。为了缩短代码使用视图、函数。

Answer 2

可读性：-当然，最好将它们分成几个易于理解的小查询并有助于维护。

性能：- 它各不相同，您必须查看执行计划才能确定这一点。 SQL Server 并行性已经很好地将查询分解为多线程搜索，但您至少让 SQL 有更好的机会提出一个好的查询计划。

我一直从分解查询中获得的一件事是，如果查询是巨大的并且在分解时运行良好，我不会收到事务日志错误。