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

这篇文章我想谈下SQL Server里一个非常重要的性能调优话题:重编译(Recompilations) 。当你执行非常简单的存储过程(使用临时表)时,就会发生。今天我想奠定SQL Server里重编译的基础,它们为什么会发生,下篇文章我会向你展示通过不同方式重写你的存储过程避免重编译。

什么是重编译?

在我谈SQL Server里重编译细节前,首先来看看下面一个很简单存储过程。

 1 CREATE PROCEDURE DemonstrateTempTableRecompiles
 2 AS
 3 BEGIN
 4     CREATE TABLE #TempTable
 5     (
 6         ID INT IDENTITY(1, 1) PRIMARY KEY,
 7         FirstName CHAR(4000),
 8         LastName CHAR(4000)
 9     )
10
11     INSERT INTO #TempTable (FirstName, LastName)
12     SELECT TOP 1000 name, name FROM master.dbo.syscolumns
13
14     SELECT * FROM #TempTable
15
16     DROP TABLE #TempTable
17 END
18 GO

从代码里可以看出,这个存储过程并没有什么特殊。第1步我们创建临时表,然后临时表里会插入一些记录,最后用简单的SELECT语句获取插入的数据。在SQL Server里,像这样的代码你可能谢了上百次,甚至上千次。

接下来我们用SQL Server Profiler跟踪下重编译事件。点击【工具】->【SQL Server Profiler】。输入登录密码后,会弹出【跟踪属性】窗口。点击【事件选择】,勾选【显示所有事件】,然后在事件列表里勾选【Stored Procedures】下列事件:

  • SP:Starting
  • SP:StmtStarting
  • SP:Recompile
  • SP:Completed

点击【运行】开始跟踪。在我们创建存储过程后,我们运行存储过程。

1 EXEC DemonstrateTempTableRecompiles

从上图可以看到,我们在执行存储过程时,发生了2次重编译。

重编译意味这SQL Server在运行执行计划时,对执行计划进行了重编译。这会带来额外的CPU开销,最后减少服务器工作的吞吐量。但现在的问题是,为什么这些重编译会发生?
SQL Server执行重编译主要是在下列2种情况发生:

  • 架构改变(Scheme Shanges)
  • 统计信息更新(Statistic Updates)

在刚才执行的存储过程里,因为这2个情况我们触发了重编译。我们再来看下刚才的存储过程,第1步我们建立了临时表,当我们在TempDb里建立临时表时,你就改变了你的数据库架构,因为这个原因第1个重编译发生了。

在临时表创建后,你插入了一些记录。因此SQL Server需要去更新临时表聚集索引的统计信息——聚集索引是由SQL Server通过主键(PRIMARY KEY)创建。1个简单的存储过程就引起了SQL Server里2个重编译。哇噢~~~~~

小结

重编译会给临时表带来巨大的性能负荷。另一方面,临时表有准确的统计信息帮助查询优化器生成更好性能的执行计划。因此,当你处理大量数据时,使用临时表才是正确选择。对于小量数据,重编译引起的CPU负荷,比通过统计信息获得性能提升的CPU负荷会高很多。

下篇文章,我会为你介绍表变量(Table Variables),我们会看到使用表变量如何避免重编译的副作用——还有它们带来的其它性能问题。请继续关注!

附:SQL Server 2014的童鞋可以使用下列脚本通过扩展事件(Extended Event)跟踪重编译事件。

 1 CREATE EVENT SESSION [TrackRecompiles] ON SERVER
 2 ADD EVENT sqlserver.sql_statement_recompile
 3 (
 4     ACTION
 5     (
 6         sqlserver.plan_handle,
 7         sqlserver.sql_text
 8     )
 9 )
10 ADD TARGET package0.event_file(SET filename = N‘c:\temp\TrackRecompiles.xel‘)
11 WITH
12 (
13     MAX_MEMORY = 4096 KB,
14     EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS,
15     MAX_DISPATCH_LATENCY = 30 SECONDS,
16     MAX_EVENT_SIZE = 0 KB,
17     MEMORY_PARTITION_MODE = NONE,
18     TRACK_CAUSALITY = OFF,
19     STARTUP_STATE = OFF
20 )
21 GO
22
23 -- Start the Event Session
24 ALTER EVENT SESSION TrackRecompiles
25 ON SERVER
26 STATE = START
27 GO
时间: 2024-08-06 14:07:43

探秘重编译(Recompilations)(1/2)的相关文章

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

原文:探秘重编译(Recompilations)(2/2) 在上一篇文章里,我讨论了使用临时表如何引起SQL Server里的重编译.在文章最后我提到,今天这篇文章我会聚焦表变量(Table Variables)的更多信息,它可以避免重编译的昂贵开销.我们来详细分析下. 表变量(Table Variables) 表变量总局限于提交到SQL Server的批处理语句范围.当你在批处理语句范围外引用表变量时,SQL Server就会返回你一条错误信息.这是和临时表相比第1个重大区别.下列代码向你展示

第11/24周 重编译

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

关于T-SQL重编译那点事,WITH RECOMPILE和OPTION(RECOMPILE)区别仅仅是存储过程级重编译和SQL语句级重编译吗

本文出处:http://www.cnblogs.com/wy123/p/6262800.html   在考虑重编译T-SQL(或者存储过程)的时候,有两种方式可以实现强制重编译(前提是忽略导致重编译的其他因素的情况下,比如重建索引,更新统计信息等等), 一是基于WITH RECOMPILE的存储过程级别重编译,另外一种是基于OPTION(RECOMPILE)的语句级重编译. 之前了解的比较浅,仅仅认为是前者就是编译整个存储过程中的所有的语句,后者是重编译存储过程中的某一个语句,也没有追究到底是不

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

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

win8.1 + VS2010 + OpenCV2.4.10重编译OpenCV开发环境搭建

win8.1 + VS2010 + OpenCV2.4.10重编译OpenCV开发环境搭建 重编译的好处:可以调试的时候看OpenCV的源代码. 重编译要得到的东西:Debug版本和Release版本的dll,lib,头文件.(dll添加到环境变量里,运行时用,自己编译的dll调试时可以跟踪到Opencv的源码内:lib和头文件配置到编译器里) PS:如果只是使用Opencv而不需要跟踪源码,则使用Opencv自带的库文件即可.跳到5配置Opencv开发环境,对应的文件都在..\opencv\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

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);

DXperience重编译汉化的方法

1. 必须有DXperience相应版本的全部源代码SourceCode.把全部源代码复制到\Program Files\Developer Express .NET vX.X\Sources目录.目标目录的默认位置是在C:\Program Files\Developer Express .NET vX.X\Sources\(其中X.X为应替换相应的版本号,以下不再重复说明).2. 必须创建一个强名称的文件.要创建此文件,必须执行下面的命令建立你自己的密钥:sn -k StrongKey.snk

SQLSERVER编译与重编译

SQLSERVER编译与重编译 编译的含义 当SQLSERVER收到任何一个指令,包括查询(query).批处理(batch).存储过程.触发器(trigger) .预编译指令(prepared statement)和动态SQL语句(dynamic SQL Statement)要完成语法解释.语句解释, 然后再进行“编译(compile)”,生成能够运行的“执行计划(execution plan)”.在编译的过程中, SQLSERVER会根据所涉及的对象的架构(schema).统计信息以及指令的