当前位置: 首页 > 编程笔记 >

sql server 编译与重编译详解

徐瀚
2023-03-14
本文向大家介绍sql server 编译与重编译详解,包括了sql server 编译与重编译详解的使用技巧和注意事项,需要的朋友参考一下

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能够很好地在编译与重编译之间做平衡,大部分情况下没什么问题的。

感谢阅读,希望能帮助到大家,谢谢大家对本站的支持!

 类似资料:
  • 我使用maven命令来清理、构建整个项目、创建war并部署到服务器。我不能使用Intellij来做这件事,因为我只有社区版。它在与intellij相同的目录中构建项目。 为了加快速度,我编写了一个脚本,可以在本地“target”目录中找到比服务器中更新的已编译文件,并进行复制。虽然一切正常,但问题是Intellij并没有将使用maven编译的类视为应该跳过并重新构建整个项目的类。 目前它的工作原理

  • 问题内容: 我已经在Scala中编程了一段时间了,我喜欢它,但是令我烦恼的是编译程序所花费的时间。这似乎是一件小事,但是使用Java可以对程序进行一些小的更改,单击netbeans中的运行按钮,然后BOOM就会运行,随着时间的推移,在scala中进行编译似乎会花费大量时间。我听说在许多大型项目中,脚本编写语言变得非常重要,因为需要花费大量的编译时间,而使用Java时却没有看到这种需求。 但是我来自

  • 本文向大家介绍基于编译虚拟机jvm—openjdk的编译详解,包括了基于编译虚拟机jvm—openjdk的编译详解的使用技巧和注意事项,需要的朋友参考一下 java只所以被推广,实际上很大原因是因为本身是跨平台的,很大作用是因为虚拟机的关系。 一般情况下开发人员不需要关注虚拟机内部实现就可以日常开发了,但是有时候涉及到性能的时候就需要了解虚拟机的实现机制了。 那么今天写的内容更多的是关于编译一套自

  • 在寻找区别时,我遇到了这些定义: 编译是将用一种语言编写的源代码转换成另一种语言的通用术语。 Transpiling是一个特定的术语,用于将用一种语言编写的源代码转换成另一种具有类似抽象级别的语言。 我明白什么是抽象。 但在上述定义中,“相似的抽象层次”是什么意思?我们如何在语言中找到抽象的层次?

  • 这个问题与android系统有关。Dalvik VM使用JIT概念,这意味着当您第一次运行应用程序时,Dalvik VM编译它并加载到RAM中,只要它能留在那里。我理解这个概念。而新的称为ART的虚拟机则使用AOT方法。ART编译应用程序后,你安装它(或当你正在安装它?)。这意味着什么?ART编译的应用程序与已编译的应用程序(如C应用程序)相同,但运行在与其他操作系统分离的独立进程中?谁能更透彻地