SQL Server資料庫對大容量表的操作

對上億的表進行排序或者上億的表之間進行join，會導致系統失去響應。

◆1.我確實做了一個很大的查詢，涉及的資料表有兩億條記錄，而且有一個group by操作，造成CPU、記憶體和磁碟開銷均很大。後來和微軟的人重新實驗了一下，我的查詢確實會造成系統反應變慢。後來我們也實驗了一下，在這個2億的表上統計一下行數，即select count(*) from table1，用了1分鐘，記憶體漲了5G左右，磁碟子系統負荷很大，CPU也突然提高。這說明這種上億的表的操作會非常嚴重的降低效率。

◆2.整個伺服器的磁碟分配是這樣的，網站訪問的資料庫庫位於磁碟陣列中，而我們的統計臨時庫位於D盤中，C和D好像是一個磁碟組，也就相當於是在C盤。我們的資料庫的大量磁碟I/O會導致系統的反應變慢。因此當我的查詢很大的時候，就會使伺服器整個系統變慢。

◆3.資料庫的資料檔案的自增長方式為每次1024k，資料檔案的空間已經接近用光，而要發生增長，而增長空間要求應該比較大，所以就會不停的申請增長，造成磁碟開銷較大。

◆4.操作中涉及到delete操作，會形成大量的日誌，而上週擴容後，發現日誌檔案比以前縮小了，估計是重建了，昨天的操作會導致日誌檔案也要不斷增長，也會造成磁碟的負荷加大。

解決辦法：

針對一：

避免大表操作，所有的操作均可以按省或者時間分開，這樣無論從時間或者地域維度，基本上可以將大表拆成30張以上的小表操作，甚至更多。然後再對結果進行合併，應該可以避免上述問題。

針對二：

無解決方案，只是建議將我們的資料庫也單獨分到一組磁碟上去，不要跟系統競爭。

針對三：

及時刪除無用的臨時資料，保障資料庫空間，同時也可以做上空間監控，一旦資料檔案空間發生增長時，給DBA一個預警郵件，我們收到郵件後可以立即做相應處理。

針對四：

日誌檔案目前已經漲得較大，我們執行一下截斷日誌的動作，將日誌檔案的空間使用保持在一個較低水平。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12639172/viewspace-450338/，如需轉載，請註明出處，否則將追究法律責任。