SQLSERVER编译与重编译发生场景及重用的利弊介绍

SQLSERVER编译与重编译初探

在SQLSERVER的世界里，每当接收到查询、批处理、存储过程、触发器等的指令时，一系列的工作便开始展开。这其中，首要环节便是“编译”。编译不仅仅是简单的语句解释，更是生成一个能够高效运行的“执行计划”的过程。在这个过程中，SQLSERVER会基于对象的架构、统计信息以及指令的具体内容，估算可能的执行计划及其成本，选择一条它认为最优的路径来执行。这些执行计划被缓存起来，对于后续的相同指令，可以直接重用，这被称为“执行计划的重用”。但有时，即使面对相同的语句，也需要进行再次的编译，这就是“重编译”。

编译的含义

当SQLSERVER接收到任何指令时，它会进行语法和语句的解释，然后进行编译，生成一个执行计划。这个计划是SQLSERVER根据指令内容、涉及的数据库对象架构和统计信息等评估出的最优路径。编译过程是一个资源消耗的过程，但生成的执行计划可以加速指令的执行。为了提高效率，SQLSERVER会把这些执行计划缓存起来，对于后续的相同指令，直接重用这些计划，而无需再次编译。

执行计划重用的利弊

执行计划的好坏直接关系到语句的执行速度。优秀的执行计划可以大大提高查询的速度。如果每次运行语句都重新编译，虽然可以确保每次都得到最优的执行计划，但也会造成资源的浪费。SQLSERVER在两者之间寻求一个平衡，尽可能地重用执行计划，以提高性能。

重编译的发生场景

有些情况下，SQLSERVER会选择不进行执行计划的重用，而是进行重编译。这主要发生在以下场景：

1. 当指令或批处理涉及的任何对象（如表或视图）的架构发生变化时。比如，在表或视图上添加或删除字段、索引或约束条件等。因为这些变化可能导致原来的执行计划不再适用，需要重新编译以获取正确的结果或提高性能。

2. 当用户在某个存储过程或触发器上运行sp_repile命令时，下一次运行这些对象时也会发生重编译。

了解SQLSERVER的编译与重编译机制，对于优化数据库性能、提高查询速度具有重要意义。希望这篇文章能为您的学习之旅提供有益的参考。关于SQL Server中的表或视图及其相关操作的编译与重编译问题

当用户在某个表或视图上运行了sp_repile操作时，所有引用到这张表（或视图）的存储过程在下一次运行前都需要进行重编译。这是为了确保数据操作的准确性及效率。

有些操作会彻底清除内存中的所有执行计划，迫使所有相关的操作进行重编译。例如，某些动作会清除整个SQL SERVER服务器缓存的所有执行计划。当Detach一个数据库、对数据库进行升级、在新的服务器上运行或是执行DBCC freeproache、reconfigure语句、alter database..collate语句修改字符集时，服务器中的所有执行计划都会被清除。而对于特定数据库的操作，如DBCC FLUSHPROCINDB可以清除SQL Server 2000服务器内存中某个数据库的存储过程缓存内容。

针对某些SET开关值的变化，如狼蚁网站SEO优化中的ansi_null_dflt_off、ansi_null_dflt_on等，这些SET开关会影响语句的执行行为，甚至导致结果不同。当这些SET开关值发生变化时，先前的执行计划都不能再重用，SQLSERVER需要根据新的设置重新制定执行计划。

值得注意的是，在SQLSERVER中，执行计划的重用并不总是有利的，而编译或重编译也不一定是坏事。虽然重用执行计划可以节省编译时间，降低CPU使用率和减少阻塞，但每次重用的计划并不一定是最合适的。例如，参数嗅探就是计划重用带来的一个负效应。而编译和重编译能为当前运行的语句带来尽可能准确的执行计划，尤其是对于那些经常运行或执行速度较慢的语句，其编译时间可能会占总时间的很大比例。

SQLSERVER能够在编译与重编译之间做出很好的平衡，大多数情况下都能正常运行，无需过多担心。但在某些特定情境下，了解这些机制有助于我们更好地优化数据库性能，确保数据的准确性与操作的效率。