SQL Server数据库的存储过程当中定义的临时表，真的有必要显式删除（drop table #tableName）吗？

 

本文出处：http://www.cnblogs.com/wy123/p/6704619.html 

 

 

问题背景

在写SQL Server存储过程当中，若是存储过程当中定义了临时表，
有些人习惯在存储过程结束的时候一个一个显式地删除过程当中定义的临时表（drop table #tName），有些人又没有这个习惯，
对于不明真相的群众或者喜欢思考的人会问，存储过程当中定义的临时表，最后要不要主动删除，为何？
或者说是否是存储过程结束的时候删除临时表更加规范？
不止一我的问过这个问题了，说实在话，本人以前确实不清楚，只是认为，显式删掉或者不删都行，临时表在当前Session断开以后会自动释放
那么存储过程当中定义的临时表，在使用完以后，到底删仍是不删？显式删除与不作删除有无区别？
本文将对此问题进行一个粗浅的分析，若有不对的地方，还望指出，谢谢。

 

存储过程当中临时表的表结构也有缓而且会被重用

那么到底需不须要显式删除,显式删除或者是不删除有什么区别？
这中间涉及到一个临时表缓存的知识点，首先看什么是临时表的缓存。
缓存临时表是SQL SERVER 2005以来的一个新特性，
临时表的建立时须要往临时库系统表中写入数据（元数据，临时表的表结构信息），跟普通的增删改操做同样，这个过程须要必定的资源消耗
在知足必定条件的状况下（后面说须要知足的条件是什么），
每当用户请求完成以后（固然这个用户请求的SQL中包含了临时表），临时表的元数据将会保存在临时库（tempdb）的系统表中
虽然在用户看来，当前Session建立的临时表，对其余Session事不可见的，在Session断开或者临时表被删除（drop）以后，将不可访问。
可是当新的Session调用一样的包含了建立临时表的代码，SQL Server内部会重用以前Session执行时建立过的临时表，而无需再次定义临时表。
这样的话能够节约一些建立表的步骤所消耗的资源。

 

上面是理论，下面来作个小实验演示上面的理论，首先来看不一样Session之间临时表“重用”的现象。
首先这里要借助系统视图sys.dm_os_performance_counters 来判断临时表的建立次数，该系统表中计数器的名称为：Temp Tables Creation Rate。

建立以下存储过程，存储过程当中定义了一个临时表，

create procedure Proc_TestTempTable
as
begin
    
    create table #t20170413
    (
        col_1 varchar(100) ,
        col_2 varchar(100)
    )

    insert into #t20170413 values ('aaa','bbb');

    select * from #t20170413
    --select * from tempdb.sys.tables where name like '#t20170413%'
end

在存储过程建立以后，第一次执行的时候，来观察一个现象，以下截图

很明显，sys.dm_os_performance_counters系统表中的Temp Tables Creation Rate计数器加了1，也就是说在执行存储过程当中过程当中发生了一次临时表的建立动做
而后继续再次执行上面的代码

一样的代码，这一次sys.dm_os_performance_counters系统表中的Temp Tables Creation Rate计数器没有加1，
为何明明是存储过程当中定义了临时表，上面执行一次，Temp Tables Creation Rate加1，而后再次执行就不加1了?
这个就是临时表重用的现象（严格说是临时表的表结构或者表定义，而不包含数据），
由于第一次执行存储过程的时候建立了临时表，而后再次执行存储过程的时候就重用了第一次的临时表。　　

　　那怎么证实该存储过程第二次执行的时候重用了第一次建立的临时表？
　　对存储过程稍做修改，存储过程当中加一句代码，查询临时库中该临时表信息

　　而后执行两次以下代码，下面截图是第二次执行的结果（下面会作解释为何是第二次的执行的结果），
　　在临时表被重用的时候查询出来当前临时表的信息，发现临时表建立次数并无增长，也就是说临时表被重用了

　　既然说临时表重用了，那么临时表必定存在于临时库的系统表中，那么如何证实这个存储过程的临时表在临时库中呢？
　　上面显示的临时表的Id是-1297292959，那么这里就临时库中查询Id = -1297292959的表信息，发现果真存在这个一张表。
　　临时库中的这个表信息除了名字和modify_date不同，modify_date据观察是临时表被重用的时间，也就是临时表被重用一次就修改一次modify_date
　　其余信息彻底一致，这就是说明，存储过程第一次执行完成以后，它所建立的临时表被缓存了起来（至于名字不一样，后面再解释），
　　当再次执行该存储过程的时候能够重用第一次执行存储过程时候建立的临时表的表结构。

 

存储过程当中显式删除临时表，到底有没有用处？

对上面的存储过程作以下修改，在存储过程结束以前显式删除定义的临时表

　　而后再次执行以下的测试代码，注意截图是第二次执行的结果（下面会作解释为何是第二次的执行的结果）

　　而后继续在临时库的系统表中查询上述Id的系统，发现临时表依旧存在于系统表中，即使是存储过程当中显式删除（drop table #t20170413）

　　这里说明，即使在存储过程当中显式调用了删除临时表的操做，临时表依旧会存在得临时库的系统表中，也就是说临时表依旧会被缓存。
　　并不会由于在存储过程当中显式删除而真正的删除，临时表对象会缓存在临时库的系统表中。
　　之因此Session中查询到的临时表的名字与系统表中查询到的临时表的名字不一样，
　　缘由是临时表从建立到缓存（当前Session断开以后），在内部只是发生了一个对当前Session临时表重命名的过程。
　　被缓存的临时表的重用的过程与上面的相似，也是将缓存的换反向重命名。

事实证实：
对于存储过程的临时表，在知足可缓存的前提下（只是表结构，固然不包括临时表的数据），
你删，或者不删，他都会缓存在临时库中，并不由于显式Drop临时表，临时表就会被真正的删除，这是SQL Server专门为此作的优化，你真的不用为删除临时表而操心或者纠结
这里回到一开始的问题，存储过程当中有没有必要显式删除临时表就有答案了：对于存储过程的建立的临时表，不必删除，对于知足可缓存的临时表对象，想删也删不掉！

 

存储过程当中定义的临时表，只有知足必定的条件，才会被缓存重用

　　上面说了，临时表的重用是要知足必定条件的，以下条件将会致使临时表没法重用

1，建立临时表的时候存在命名约束（这一点很是操蛋，不只仅是缓存问题，曾经遇到过坑，有机会演示）
2，在临时表建立以后执行DDL操做，好比建立索引等，可是这个DDL不包括drop 临时表和truncate临时表
3，动态SQL方式建立的临时表
4，在不一样的范围以内建立的临时表，应该是存储过程调用另一个存储过程，另一个存储过程定义的临时表，这一点尚未具体研究
5，存储过程以WITH RECOMPILE重编译的方式运行

　　好比在上面的存储过程，在临时表定义以后，建立一个索引，
　　此举将会形成临时表没法重用，这种状况下，无论你删或者不删，存储过程执行完成Session断开以后，临时表都不会缓存（在临时库中）
　　这一点就不截图演示了，有兴趣的本身测试

 

　　解释另一个问题：
　　既然认为没法删除缓存的临时表，正常状况下，缓存的临时表什么状况下会被删除？
　　上面说截图都是第二次运行的截图，由于在存储过程重建以后（create或者alter），这个存储过程当中定义的临时表都会被清理掉
　　只有重建了存储过程，第一次执行以后，缓存的临时表在第二次执行的时候才能被重用
　　固然这一点也和容易验证，缓存临时表以后，而后alter 存储过程，
　　而后根据缓存临时表的Id去查询临时库中sys .tables的信息，这个缓存的表会在1~2秒以后被删除（我的测试验证过）
　　另外显式执行DBCC FREEPROCCACHE，也能删除缓存的临时表。
　　其实也不难理解，缓存的对象是跟执行计划缓存绑定的，若是执行计划自己就不存在了，那么缓存的临时表对象也将会被请处理。

 

并发执行的状况下，临时表可否重用？

　　并发线程之间固然不会重用同一个临时表，若是不是这样的话，SQL Server也不用混江湖了，并发的每一个线程会建立本身的临时表。
　　参考以下截图是在并发状况下，tempdb产生的临时表的状况，每一个线程调用存储过程产生的临时表后缀都是不同的。
　　并发调用存储过程的时候，每一个线程会产生属于本身的临时表，重用临时表是发生在当前线程执行完成以后，其余Session从新调用存储过程时候才能重用已缓存的临时表。
　　鉴于本文不是专门说明临时表的，这里就很少说了。

　　

 

显式删除临时表与否的性能测试

既然上面说了，若是存储过程当中定义的临时表知足临时表被缓存的条件的状况下，存储过程当中是否删除临时表，临时表都同样会被缓存
那么，若是真的指定了显式删除临时表操做，与没有显式指定删除临时表，性能上有没有差异呢？
抱着以数听说话的态度，分别在存储过程当中不删除与显式删除临时表，用SQLQueryStress作了一系列的性能测试
结果以下

不显式删除临时表	显式删除临时表

测试结果以下， 

　　

　　测试过程部分截图（不浪费博客园的图片服务器资源了，随便截了两张）

　　

　　从测试结果看，确实有一些差别，不过这个差异是很是小的，
　　第一组测试结果5000次调用产生了0.07秒的差距
　　第二组测试结果20000次调用产生了0.35秒的差距，平均到一次差距也就在微妙级，即使是显式调用删除，对性能来讲是有一点点影响，不过这个影响也是无伤大雅。
　　不过这个内部的原始必定要弄清楚，有没有必要删除，以及缘由，这个才是原则性的问题！

　   至于临时表数据占用的空间，也不是说显式删除就释放，不删除就不释放，应该是有后台进程来作这个工做的，我的建议不用为这个问题瞎操心。
　　写存储过程的时候，多写一点好一点的SQL语句，比纠结这个强多了。

多啰嗦一句：
有些人的观念是根深蒂固的，对于习惯删除临时表的人，以为这么作“规范”，“专业”，虽然他没有确切的理由说明显式删除临时表的必要性。
可是你要跟他说不必删除临时表，必定会激怒他，好多程序员都是这样的，你否定他根深蒂固的一个观点的时候，他是很恼火的。
从生物学上说，这个是属于“印随行为”，如宗教般，在本身处于懵懂期的时候，受到一些说法的影响
或许是当初的师傅说的，或者膜拜的对象这么作了，或者听高人说过这么作比较好，而后本身就一直这么作了而且坚信不疑。
固然，包括我本身在某些时候也有此种行为，思惟被曾经的某一些经历固化，而后一直束缚本身的认知。
不过对于无伤大雅的问题，就随他去了，不必说服他，弄很差他反过来以为你业余，但愿小伙伴们明辨，好彷佛跑题了……

 

显式删除临时表与否与临时库空间释放问题

　　有人担忧说，若是不显式删除临时表，是否是临时表占用的空间没法快速释放？
　　其实也不用顾虑，仍是以数听说话，这里对比两个同样的存储过程，一个不显式删除临时表，一个显示删除临时表，看看临时数据库中用户对象占用page的状况
　　不显式删除临时表的存储过程
　　作以下对比测试，借助SQLQueryStress，作一个20线程，每一个线程500次循环的测试

      

　　测试的过程当中，在临时数据库中，利用以下SQL，间隔一秒的频率抓取临时库中user objects对象的数据

　　

　　把上述脚本记录到的数据，利用Excel的透视图功能，呈现出来上述脚本记录到的user objects数量，能够很清楚地发现，不显式删除临时表，与显式删除临时表相比，UserObjecs数量并无明显的差别
　　也就数说，不显式删除临时表的状况下，并无出现临时表空间对象释放不及时的状况

　　

 　　所以大可没必要担忧，不显式删除临时表，临时表申请的空间没法及时释放。

　　

总结：　　　

　　本文从存储过程当中的临时表是否须要显式删除入手，简单介绍了临时表重用的现象和前提条件，以及有无必要显式删除临时表，
　　同时测试了临时表在知足重用的状况下，临时表显式删除与否的性能问题，对于存储过程当中定义的临时表，无论是否可否缓存重用，都不建议显式删除。

 

参考连接：https://www.mssqltips.com/sqlservertip/4406/sql-server-temporary-table-caching/
　　　　　http://sqlblog.com/blogs/paul_white/archive/2012/08/17/temporary-object-caching-explained.aspx

 　　　　 http://www.davewentzel.com/content/do-you-explicitly-drop-your-temp-tables