SQLSERVER编译与重编译

SQLSERVER编译与重编译

编译的含义



当SQLSERVER收到任何一个指令,包括查询(query)、批处理(batch)、存储过程、触发器(trigger)

、预编译指令(prepared statement)和动态SQL语句(dynamic SQL Statement)要完成语法解释、语句解释,

然后再进行“编译(compile)”,生成能够运行的“执行计划(execution plan)”。在编译的过程中,

SQLSERVER会根据所涉及的对象的架构(schema)、统计信息以及指令的具体内容,估算可能的执行计划,

以及他们的成本(cost),最后选择一个SQLSERVER认为成本最低的执行计划来执行。执行计划生成之后,

SQLSERVER通常会把他们缓存在内存里,术语统称他们叫“plan cache”以后同样的语句执行,SQLSERVER就可以使用同样的执行计划,而无须再做一次编译。

这种行为叫“重用(reuse)或者叫重用执行计划”。但是有时候,哪怕是一模一样的语句,SQL下次执行还是要再做一次编译。

这种行为叫“重编译(recompile)”。执行计划的编译和重编译都是要消耗资源的。

如果执行计划能够重用,那么SQLSERVER就不需要再执行上面的过程,加快执行指令的速度,很多语句调优的文章里提到数据库重用执行计划就是指这个意思

执行计划重用的利弊



执行计划的好坏当然决定了语句最终的执行速度。对于同样的一条语句,使用好的执行计划可能会比差的要快几百倍,甚至上千倍。

所以从这一个角度来讲,每运行一条语句,都把他先编译一遍当然是最好的。他能够保证使用的执行计划是SQLSERVER能找到的最优的。

但是SQLSERVER每秒钟可能会运行成百上千的指令。如果每个都编译一遍,是资源的一种浪费。所以SQLSERVER在这里也试图寻找一个平衡点,

使用有限的compile/recompile,得到最好的整体性能

运行下面的指令,就能够看到SQLSERVER当前缓存的执行计划有哪些(请别在生产服务器上直接运行因为上面往往有庞大的缓存)

1 SELECT * FROM sys.[syscacheobjects]

重编译的发生场景



但是有些时候,SQLSERVER为了确保返回正确的值,或者有性能上的顾虑,有意不重用缓存在内存里的执行计划,而现场编译一份。

这种行为,被称为重编译(recompile)。下面是比较常见的会发生重编译的情形:

1、当指令或者批处理所涉及的任何一个对象(表格或者视图)发生了架构(schema)变化

例如,在表或者视图上添加或删除了一个字段,添加或者删除了一个索引,在表上添加或者删除了一个约束条件(constraints)等。

定义发生了变化,原来的执行计划就不一定正确了,当然要重编译

2运行过sp_recompile

当用户在某个存储过程或者触发器上运行过sp_recompile后,下一次运行他们就会发生一次重编译。

如果用户在某个表或者视图上运行了sp_recompile,那么所有引用到这张表(或者视图)的存储过程在下一次运行前,都要做重编译

3、有些动作会清除内存里的所有执行计划,迫使大家都要做重编译

例如,下列动作会清除整个SQLSERVER服务器缓存的所有执行计划:

(1)Detach一个数据库

(2)对数据库做了升级,在新的服务器上,会发生执行计划清空

(3)运行了DBCC freeproccache

(4)运行了reconfigure语句

(5)运行了alter database..collate语句修改了某个数据库的字符集(collation)

下列动作会清除SQLSERVER服务器缓存的某个数据库的执行计划:

DBCC FLUSHPROCINDB

清除SQL Server 2000服务器内存中的某个数据库的存储过程缓存内容

1 DECLARE @a INT
2 SELECT @a=DB_ID(‘gposdb‘)
3 DBCC flushprocindb(@a)

ALTER DATABASE ...MODIFY NAME语句

ALTER DATABASE ...SET ONLINE语句

ALTER DATABASE...SET OFFLINE语句

ALTER DATABASE...SET EMERGENCY语句

DROP DATABASE 语句

当一个数据库自动关闭时

DBCC CHECKDB语句结束时

4、当下面这些SET 开关值变化后,先前的那些执行计划都不能重用

ansi_null_dflt_off,

ansi_null_dflt_on,

ansi_nulls,

_ansi_padding

ansi_warnings,

arithabort,

concat_null_yields_null,

datefirst,dateformat,

forceplan,

language,

no_browsetable,

numeric_roundabort,

quoted_identifier

这是因为这些SET开关会影响语句的执行的行为,甚至带来不同的结果。他们发生变化了,SQLSERVER就要根据新的设置重做执行计划

5、当表格或者视图上的统计信息发生变化后

当统计信息被手动更新后,或者SQLSERVER发现某个统计信息需要自动更新时,SQLSERVER会对所涉及的语句都做重编译

需要说明的是,在SQLSERVER里,执行计划重用并不一定是一件好事,而编译/重编译也不一定是一件坏事。

计划重用可以帮助SQLSERVER节省编译时间,对降低CPU使用率和减少阻塞都有好处,但是缺点是每次重用的计划并不一定是最合适的计划。

参数嗅探parameter sniffing就是典型的计划重用带来的负效应。编译和重编译当然能给当前运行的语句带来尽可能准确执行计划,

但是对于经常运行的语句,尤其是一些执行速度比较快的语句,可能其编译时间占最后总时间的相当大比例。这对资源来讲是一个很大的浪费 

一般来说,SQLSERVER能够很好地在编译与重编译之间做平衡,大部分情况下没什么问题的。

时间: 2024-10-26 01:22:25

SQLSERVER编译与重编译的相关文章

[转]Android应用安装包apk文件的反编译与重编译、重签名

背景介绍: 最近在做Robotium自动化测试,使用到solo.takeScreenshot()函数以在测试过程中截图,但此函数需要被测试APP具有<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />权限.在只有被测试APP的apk文件的情况下,修改apk文件后缀名为zip,解压缩后,修改AndroidManifest.xml文件,删除META-INF文件夹,重压缩为apk文

Unity3D对apk反编译、重编译、重签名

本文源链接:http://blog.csdn.net/qq393830887/article/details/56025923 工具 Java环境 Apktool(这玩意有些坑爹,不是官网最新的就好,找到一个好用的版本能少很多坑) Apktool Jarsigner 反编译 var argList = ProcessHelper.CreateArgumentsContainer(); argList.Add("java -jar"); argList.Add(ApkToolPath);

【Android 应用开发】 Android APK 反编译 混淆 重编译

反编译工具 : 总结了一下 linux, windows, mac 上的版本, 一起放到 CSDN 上下载; -- CSDN 下载地址 : [email protected]:~/decompiler$ tree -L 2 . ├── linux │   ├── apktool │   ├── dex2jar-0.0.9.15 │   └── jd-gui ├── mac │   ├── apktool │   ├── dex2jar-0.0.9.15 │   └── jd-gui-0.3.5.

探秘重编译(Recompilations)(1/2)

这篇文章我想谈下SQL Server里一个非常重要的性能调优话题:重编译(Recompilations) .当你执行非常简单的存储过程(使用临时表)时,就会发生.今天我想奠定SQL Server里重编译的基础,它们为什么会发生,下篇文章我会向你展示通过不同方式重写你的存储过程避免重编译. 什么是重编译? 在我谈SQL Server里重编译细节前,首先来看看下面一个很简单存储过程. 1 CREATE PROCEDURE DemonstrateTempTableRecompiles 2 AS 3 B

DevExpress Components16.2.6 Source Code 重编译教程

http://www.cnblogs.com/Soar1991/p/6669862.html DevExpress 是一个比较有名的界面控件套件,提供了一系列优秀的界面控件.这篇文章将展示如何在拥有源代码的情况下,对 DevExpress 的程序集进行重新编译. 特别提示:重编译后,已安装好的 DevExpress Demo 项目都将无法正常运行,需要将 Demo 也进行重编译操作后,方可恢复正常,新手请注意. 系统必备 Windows 7 SP1 以上操作系统 Visual Studio 20

第11/24周 重编译

今天我想谈下性能调优培训里的重编译(Recompilations ).当你执行一个查询,SQL Server里另一个变动使你执行计划的剩余部分无效,就会发生重编译.在那个情况下SQL Server需要保证你执行计划的准确性,重编译就会被触发.重编译会给你的SQL Server带来额外的CPU开销. 什么是重编译? 首先我想展示下编译和重编译之间的区别.2个星期前,我们讨论了SQL Server里的编译.当查询优化器把提交的查询转化为实际执行计划时,编译就会发生.这就是说编译在查询执行开始前就发生

sqlserver 存储过程中使用临时表到底会不会导致重编译

曾经在网络上看到过,SqlServer的存储过程中使用临时表,会导致执行计划无法重用, 运行时候会导致重编译的这么一个说法,自己私底下去做测试的时候,根据profile的跟踪结果, 如果不是统计信息变更导致导致的重编译,单单是使用临时表,并不会导致重编译, 但是对于一些特殊的情况,又确实会出现重编译的, 为了弄清楚这个问题,查阅了大量的资料,才把这个问题弄清楚,这里特意记录下来,希望武断地认为存储过程中使用了临时表就会导致重编译的这个观点得到纠正. 首先进行下面的测试,我们知道,导致临时表重编译

SQL SERVER 临时表导致存储过程重编译(recompile)的一些探讨

SQLSERVER为了确保返回正确的值,或者处于性能上的顾虑,有意不重用缓存在内存里的执行计划,而重新编译执行计划的这种行为,被称为重编译(recompile).那么引发存储过程重编译的条件有哪一些呢?下面罗列了一些导致重编译(recompile)的条件:     - 对查询所引用的表或视图进行更改(ALTER TABLE 和 ALTER VIEW).     - 对执行计划所使用的任何索引进行更改.     - 对执行计划所使用的统计信息进行更新,这些更新可能是从语句(如 UPDATE STA

WITH RECOMPILE和OPTION(RECOMPILE)区别仅仅是存储过程级重编译和SQL语句级重编译

在考虑重编译T-SQL(或者存储过程)的时候,有两种方式可以实现强制重编译(前提是忽略导致重编译的其他因素的情况下,比如重建索引,更新统计信息等等), 一是基于WITH RECOMPILE的存储过程级别重编译,另外一种是基于OPTION(RECOMPILE)的语句级重编译. 之前了解的比较浅,仅仅认为是前者就是编译整个存储过程中的所有的语句,后者是重编译存储过程中的某一个语句,也没有追究到底是不是仅仅只有这么一点区别. 事实上在某些特定情况下,两者的区别并非仅仅是存储过程级重编译和语句级重编译的