改变数据库增长率是否会迫使新的执行计划？

Question

多年来，一直有一个长时间运行的 SQL 代理作业需要近两个小时才能完成。大约两周前，出于一个小小的突发奇想，决定改变相关数据库的增长率。此后，这项工作在不到 30 分钟的时间内就完成了。改变日志的增长率会强制生成新的执行计划。我只是好奇 SQL Server 内部发生了什么，这会导致更快的运行时间。

谢谢

Answer 1

我只是好奇 SQL Server 内部发生了什么，这会导致更快的运行时间。

当查询正在运行并且事务日志文件需要增长时，会发生一堆事情，这将不可避免地减慢查询的总运行时间。

这些事项的非详尽清单包括：

• 查询进入等待状态，
• SQL Server 可能必须等待其他并发查询完成才能获得对事务日志文件的独占访问权限，
• SQL Server 调用 Windows 文件 API 来增长日志文件（这取决于驱动程序、Windows 任务调度、磁盘速度等），
• 日志文件必须“清零”，
• 查询必须重新开始并从中断处恢复处理。

如果此作业确实生成了大量事务日志（即，它执行插入、更新和删除），则可能会导致日志增长。如果您将日志文件的“filegrowth”设置增加到更高的值，那么这个大文件增长操作将不那么频繁地发生，并且整个作业将运行得更快（正如您所观察到的）。

上述所有内容对于数据文件增长来说基本上也是如此，只是数据文件不一定需要清零（如果您启用了“即时文件初始化”（IFI））。

数据和日志文件增长设置的默认值非常低，尤其是在旧版本的 SQL Server 上。 一项建议是将它们分别设置为 256 MB 和 128 MB。无论增长设置如何，您都应该尽可能避免这些文件增长事件，尤其是在时间敏感的操作期间。

对于事务日志的增长，这可能意味着一次执行较小批量的工作，或更频繁地进行日志备份等。

对于数据文件，这可能意味着在维护窗口期间当您的监控警告文件即将满时启用 IFI 并定期手动增长数据文件。

正如我希望从我的回答中可以清楚地看出，执行计划的更改似乎不太可能导致您看到的性能差异。但要回答标题中的问题，我刚刚意识到我忘记了：

改变数据库增长率是否会迫使新的执行计划？

我实际上不确定更改数据文件增长设置是否会使计划缓存失效，但我认为不会。