临时表和表变量定序问题引起

前两天在写存储过程的时候遇到编号 468 的错误，看一下，是定序错误，因为是用的临时表，所以查看了下tempdb的定序，发现两个数据库定序不一致，
原本想把定序改为一致，执行T-SQL修改了定序，结果是数据库和TABLE的定序改了，但列的定序还是原来的【无力吐槽】。后想了些办法来修改数据库定序，
因为时间关系，放弃了。修改了了临时表中的定序，执行后还是出现问题，晚上同事帮忙改了一下，可以执行了。回头看了下，解决办法是将其中一个临时表
改成了表变量，看了下代码，发现只修改了一个临时表的定序【二个临时表】，造成问题只解决一半，由于表变量也解决了问题，为了弄清楚原委。
查找了相关资料，特转截下面文章，感谢同事及文章作者

表变量与临时表的优缺点：
转自：http://www.cnblogs.com/Mainz/archive/2008/12/20/1358897.html

什么情况下使用表变量？什么情况下使用临时表？

表变量：  

  DECLARE @tb  table(id   int   identity(1,1), name   varchar(100))   
  INSERT @tb  

  SELECT id, name 
  FROM mytable 

  WHERE name like ‘zhang%’ 

 

临时表： 

  SELECT name, address
  INTO #ta   FROM mytable  
  WHERE name like ‘zhang%’

 

表变量和临时表的比较：

• 临时表是利用了硬盘(tempdb数据库) ，表名变量是占用内存，因此小数据量当然是内存中的表变量更快。当大数据量时，就不能用表变量了，太耗内存了。大数据量时适合用临时表。
• 表变量缺省放在内存，速度快，所以在触发器，存储过程里如果数据量不大，应该用表变量。
• 临时表缺省使用硬盘，一般来说速度比较慢，那是不是就不用临时表呢？也不是，在数据量比较大的时候，如果使用表变量，会把内存耗尽，然后使用 TEMPDB的空间，这样主要还是使用硬盘空间，但同时把内存基本耗尽，增加了内存调入调出的机会，反而降低速度。这种情况建议先给TEMPDB一次分配合适的空间，然后使用临时表。
• 临时表相对而言表变量主要是多了I/O时间，但少了对内存资源的占用。数据量较大的时候，由于对内存资源的消耗较少，使用临时表比表变量有更好的性能。
• 建议：触发器、自定义函数用表变量；存储过程看情况，大部分用表变量；特殊的应用，大数据量的场合用临时表。
• 表变量有明确的作用域，在定义表变量的函数、存储过程或批处理结束时，会自动清除表变量。
• 在存储过程中使用表变量与使用临时表相比，减少了存储过程的重新编译量。
• 涉及表变量的事务只在表变量更新期间存在。这样就减少了表变量对锁定和记录资源的需求。
• 表变量需要事先知道表结构，普通临时表，只在当前会话中可用与表变量相同into一下就可以了,方便；全局临时表：可在多个会话中使用存在于temp中需显示的drop。（不知道表结构情况下临时表方便一些）
• 全局临时表的功能是表变量没法达到的。
• 表变量不必删除，也就不会有命名冲突，临时表特别是全局临时表用的时候必须解决命名冲突。
• 应避免频繁创建和删除临时表，减少系统表资源的消耗。
• 在新建临时表时，如果一次性插入数据量很大，那么可以使用select into代替create table，避免log，提高速度；如果数据量不大，为了缓和系统表的资源，建议先create table，然后insert。
• 如果临时表的数据量较大，需要建立索引，那么应该将创建临时表和建立索引的过程放在单独一个子存储过程中，这样才能保证系统能够很好的使用到该临时表的索引。
• 如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先truncate table，然后drop table，这样可以避免系统表的较长时间锁定。
• 慎用大的临时表与其他大表的连接查询和修改，减低系统表负担，因为这种操作会在一条语句中多次使用tempdb的系统表。