艾锑知识 |sql server 编译与重编译详解

2020-03-04 17:48 作者：admin 浏览量：

 
疫情放慢了管理者的脚步,却没有放慢管理者的心,对于企业来说,在富有的时候,可以说说情怀,说说理想,但在贫穷受困的时候,没有饭吃的时候,情怀和理想其实并不重要,重要的是下一顿吃什么?在哪吃呢?
 
前几天,有篇文章报道某云南大型企业的人事总监被总经理怒骂的邮件很火,为什么会发生这样的事,我觉得身为一个企业的员工,无论你处在什么岗位,什么职位,一定要审时度势,要知道企业要什么,俗话说,大河有水小河满,只有企业活下来了,活好了,组织里的员工才能真正拿到自己想要的,如果在危难时机,你还在坚持自己观点,抱持着自己的思维不改变,不能与企业思想同步,那最终也不会有什么好的结果.
 
在这里艾锑无限给已经上班或即将上班的各个企业伙伴一些忠告:
 
1,困难时期,在为自己着想的同时多想想能为企业做点什么,今天你的付出,明天不一定会有收获,但长久来看,能量守恒定律,你是不会吃亏的.
 
2,在经济还没复苏的时期,企业还不太忙的时候,除了做好自己部门手头上的工作以外,把自己的大脑开动起来,如果你是职员,就想想假如你是这个部门经理,你如何做可以让部门的损失降到最低,让收益提升到最大.如果你是经理就想想假如你是企业的CEO,你如何做可以让企业快速恢复状态,让业务快速发展起来,让现金流可以流动起来?
 
3,如果你处在花钱的部门,就想想如何做可以省钱,又可以为部门创收,如果你是创收的部门,就想想原来从来就没想过的问题,因为你不能破旧就不能立新,不能创造就是在消耗.
 
4,管理团队间,如果不是能力问题,不仅行动要勤快,大脑更要勤快一些,除了思考自己部门的工作,也要思考其他部门的工作,你的团队可以做些什么更利于其他部门的发展,你可以做些什么更助于其他管理者达成目标,整个企业就像一台齿轮吻合的机器,只有彼此主动吻合才能让这台机器更好的运转,这也像打群架,如果每一个人都能照顾好自己,还能为他人着想,就不会受伤,也能全身而退,有一个人需要他人照顾,就很可能有人受伤,并导致全队受损.
 
5,无论什么时期,不要害怕困难,不要拒绝烦恼, 烦恼即菩提,菩提即智慧,伟大的洞见和上师都是来自于苦难和无数次的折磨.相信宇宙的安排,无论是事,还是人,来到你的身边就是成就你的,所以把心安于当下,尽一切努力做到尽善尽美.
 
接下来分享一则技术信息,以许会对你的企业有所帮助:
 
 
艾锑知识 |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能够很好地在编译与重编译之间做平衡，大部分情况下没什么问题的。