SQL Server的tempdb很大的解决方法

1.建议先重起SQL Server服务或服务器（引发的问题：服务器暂停，且可能丢失部分数据），故建议在晚上无人使用时进行。

2.修改tempdb的初始大小,不要用默认大小，例如限制tempdb的大小，以观后效。

3.如果可以，请优化sql 语句

4.定期重起SQL Server服务 或  服务器

5. 可以做一个作业，每天自动执行收缩

6. 为tempdb提供独立硬盘（如：256G SSD）

大多数人人认为tempdb是用于临时表的. 其实, 你根本不需要建临时表就可以很容易的使tempdb增大. 比如:

 1. 任何排序查询使用的memory超过了SQL SERVER所被分配的memory, 该查询就会被强制在tempdb里进行.
 2. 任何排序所要求的空间超过了tempdb被分配的空间
 3. DBCC CHECKDB是使用tempdb的空间进行的. 当遇到较大的表是, 会"吃掉"很多tempdb的空间.
 4. DBCC DBREINDEX或者其他DBCC..with 'Sort in tempdb'选项的也会占用很多tempdb的空间.
 5. unions, order by / group by, cartesian joins, outer joins, cursors, temp tables, table  
    variables, 和 hashing等所产生的大的查询结果也很占tempdb的空间.
 6. 任何没commit和roll back的事务会留在tempdb里
 7. 使用ODBC DSN加上'建临时存储过程'选项的, 会在连接其间把创建的object留在tempdb里.

下面的语句告诉你tempdb的分配空间:

de>use tempdbde>

de>gode>

de>execde> de>sp_spaceusedde>

de>gode>

 下面的代码告诉你那些表占用了tempdb的很多空间 -- 这可以使你缩小查询范围: 看那些事务运行了很长时间或经常被留在tempdb里:

de>USE tempdb de>

de>GO de>

de>SELECTde> de>namede> 

de>    FROMde> de>tempdb..sysobjects de>

de> de> 

de>SELECTde> de>OBJECT_NAME(id), rowcnt de>

de>    FROMde> de>tempdb..sysindexes de>

de>    WHEREde> de>OBJECT_NAME(id) LIKEde> de>'#%'de> 

de>    ORDERde> de>BYde> de>rowcnt DESCde>

 较大的rowcount值说明比较大的临时表占用了tempdb的空间. 当然, 因为tempdb用于内部I/O和其他排序过程, 所以可能你看不出什么来. 不过, 你还是可以缩小调查范围的.(比如, 你可以再通过查询INFORMATION__SCHEMA.ROUTINES..WHERE ROUTINE_DEFINITION LIKE '%#table_name%' 来查询哪个存储过程占用了很多tempdb空间)
 另外, 你可以用profiler来看数据库文件和日志文件的auto grow事件, 如果有, 说明你设置的tempdb空间不够大.

短期的补救方式:
 1. shrink tempdb .
 2. 用DBCC OPENTRAN看看有没有长时间运行的事务(一般是因为没commit), 然后可以的话, 用KILL把该session终止.
 3. 重启

 长期的方法:
 tempdb这个临时数据库，它对性能的影响较大。tempdb和其他数据库一样可以增大，可以缩小。当数据文件需要增长的时候，通常不能保持剩余部分的连续性。这时文件就会产生碎片，这种碎片会造成性能下降。这种碎片属于外来性碎片。要阻止在tempdb中产生外来性碎片，必须保证有足够的硬盘空间。一般将tempdb的容量放到平均使用容量。而你也应该允许tempdb自动增长，比如你有个一个超大的join操作，它建立了一个超过tempdb容量的时候，该查询将失败。你还要设置一个合理的单位增长量。因为如果你设得太小，将会产生许多外来性碎片，反而会占用更多资源。sqlserver调优最有效的做法之一，就是把争夺资源的操作独立出去。tempdb就是一个需要独立出去的部分而tempdb和其他系统库一样是公用的，是存取最可能频繁的库，所有处理临时表、子查询、GROUP   BY、排序、DISTINCT、连接等等。它最适合放到一个具有快速读写能力的设备上

 

 

 

 

综上所述：
 1) tempdb没在单独的硬盘上，或者是硬盘空间太小.。
 2) 既然经常增大，说明商务活动需要很大的tempdb，也就说明设置的tempdb的初始空间太小。如果经过分析后, 没什么别的异常, 比如：没有长时间运行的事务等，那更说明该tempdb应该设置较大的空间。