SQL Server數據庫對上億表的操作
導讀：SQL Server數據庫的功能性很好，盡管如此，在面對上億表的操作時，SQL Server數據庫還是不行，速度很明顯就慢下來啦，那么如何讓SQL Server數據庫在處理上億表時，仍能夠實現很高的工作效率呢？
大數量的操作帶來的影響：
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一個預警郵件，我們收到郵件后可以立即做相應處理。
針對四：
日志文件目前已經漲得較大，我們執行一下截斷日志的動作，將日志文件的空間使用保持在一個較低水平。
上文中首先是為大家分析出了這個問題的所在，緊接著，又為大家總結出了解決方案，相信已經是非常清楚明白啦，希望能夠對大家有所幫助。
【編輯推薦】
