在SQL Server中，TempDB主要負責供下述三類情況使用：
內部使用（排序、hash join、work table等)
外部使用（臨時表，表變量等）
行版本控制（樂觀並發控制）
而對於內部使用，一些比較復雜的查詢中由於涉及到了大量的並行、排序等操作時就需要大量的內存空間，每一個查詢在開始時都會由SQL Server預估需要多少內存，在具體的執行過程中，如果授予的內存不足，則需要將多出來的部分由TempDB處理，這也就是所謂的Spill to TempDB。
通過下述語句可以觀察到某個查詢對TempDB造成了多少讀寫：
DECLARE @read BIGINT,
@write BIGINT
;
SELECT @read = SUM(num_of_bytes_read),
@write = SUM(num_of_bytes_written)
FROM tempdb.sys.database_files AS DBF
JOIN sys.dm_io_virtual_file_stats(2, NULL) AS FS
ON FS.file_id = DBF.file_id
WHERE DBF.type_desc = 'ROWS'
--這裡放入需要測量的語句
SELECT tempdb_read_MB = (SUM(num_of_bytes_read) - @read) / 1024. / 1024.,
tempdb_write_MB = (SUM(num_of_bytes_written) - @write) / 1024. / 1024.,
internal_use_MB =
(
SELECT internal_objects_alloc_page_count / 128.0
FROM sys.dm_db_task_space_usage
WHERE session_id = @@SPID
)
FROM tempdb.sys.database_files AS DBF
JOIN sys.dm_io_virtual_file_stats(2, NULL) AS FS
ON FS.file_id = DBF.file_id
WHERE DBF.type_desc = 'ROWS'
最近在一個客戶那裡看到的爛查詢所導致的TempDB使用結果如下:
使用該查詢就可以幫助了解某個語句使用了多少TempDB。
SQL Server 2000對於TempDB的處理是采用SQL Server Cache Buffer Manager來管理，而不再是象SQL Server 7.0一樣可以使用TempDB In RAM的，這樣，在高並發情況下，由於SQL Server的後台進程不能及時調度，造成TempDB的容量迅速增大（由初始的8MB增長到性能測試時的800MB），從而導致 Cache Hit Ration迅速下降造成對TempDB的 Pages Reads/Sec和Pages Writes/Sec狂飙造成的。 TEMPDB增長的同時也會導致內存使用的增長，由於內存以及物理空間的資源使用，從而導致系統的整體性能下降。 解決方法： 定期收縮TEMPDB數據庫，可以采用下面幾種方式，最好做一個定期執行計劃 方法1、重啟SQL SERVER服務 ALTER DATABASE tempdb MODIFY FILE (NAME = 'tempdev', SIZE = 需要收縮的大小) ALTER DATABASE tempdb MODIFY FILE (NAME = 'templog', SIZE =需要收縮的大小) 方法2、 sp_spaceused @updateusage=true dbcc shrinkdatabase (tempdb, '百分比') 方法3、 dbcc shrinkfile (tempdev, '需要收縮的大小') dbcc shrinkfile (templog, '需要收縮的大小')
SQL Server會自動創建一個名為tempdb的數據庫作為工作空間使用，當您在存儲過程中創建一個臨時表格時，比如(CREATE TABLE #MyTemp)，無論您正在使用哪個數據庫，SQL數據庫引擎都會將這個表格創建在tempdb數據庫中。
而且，當您對大型的結果集進行排序，比如使用ORDER BY或GROUP BY或UNION或執行一個嵌套的SELECT時，如果數據量超過了系統內存容量，SQL數據庫引擎就會在tempdb中創建工作表格。在您運行DBCC REINDEX或者向現有的表格中添加集群序列時， SQL數據庫引擎同樣會使用tempdb。實際上，任何針對大型表格的ALTER TABLE命令都會在tempdb中吃掉大量的磁盤空間。
在理想狀態下，SQL會在完成指定操作後自動清理，並銷毀這些臨時表格，但是，很多問題都會導致錯誤。比如，您的代碼創建了一個事務，但是卻沒能執行或重新運行，那麼這些孤兒對象將遺留在tempdb中。而且，對大型數據庫運行DBCC CHECK時，它還會消耗掉大量的空間，您往往會發現tempdb比設想的要大很多，甚至還會收到SQL即將用完磁盤空間的出錯信息。
您有很多方法可以來修正這一情況，但從長遠看來，您需要執行其它的步驟來保證正常使用。
為tempdb“減肥”最簡單的辦法就是關閉SQL數據庫引擎然後重新啟動，但是在重要的任務中，這樣做可能難度很大；另一方面，如果您已經處於無法承受的狀態，那麼我的建議就是將這個壞消息告知您的上司，然後開始操作。
如果您幸運擁有另外一塊磁盤可以用來放置tempdb，可以進行如下的操作：
USE master
GO
ALTER DATABASE tempdb modify file (name = tempdev, filename ='NewDrive:Path empdb.mdf')
GO
ALTER DATABASE tempdb modify file (name = templog, filename ='NewDrive:Path emplog.ldf')
GO
還有三項關於tempdb的屬性應該檢查：自動增長標記，初始大小和恢復模式，以下是關於這些屬性的小竅門：
自動增長標記：記住將這個標記設為True。
初始大小：tempdb的初始大小要根據常用的工作負載來設定，如果有很多用戶在使用GROUP BY、ORDER BY或者對大型表格進行聚合操作，那麼您的常用工作負載會相當大。如果服務器脫機時，您可能需要檢查日志文件與數據文件是否位於同一磁盤，如果這樣的話，應當將需要將它們轉移到新的磁盤上，您只需指明相應的數據庫並使用相同的命令即可。
恢復模式：將恢復模式設定為True意味著讓SQL自動截去tempdb的日志文件（在使用了每個表格之後），要找出tempdb所使用的恢復模式，可以使用如下命令：
SELECT DATABASEPROPERTYEX('tempdb','recovery')
恢復模式有三種選擇：簡單、完整或大量記錄（bulk-logged），如要改變設置，可以使用以下命令：
ALTER DATABASE tempdb SET RECOVERY SIMPLE
這些步驟可以優化您系統中使用的tempdb，除了解決磁盤空間問題外，您還會發現SQL Server系統性能的提升。...余下全文>>
