對上億的表進(jìn)行排序或者上億的表之間進(jìn)行join，會導(dǎo)致系統(tǒng)失去響應(yīng)。

◆1.我確實(shí)做了一個(gè)很大的查詢，涉及的數(shù)據(jù)表有兩億條記錄，而且有一個(gè)group by操作，造成CPU、內(nèi)存和磁盤開銷均很大。后來和微軟的人重新實(shí)驗(yàn)了一下，我的查詢確實(shí)會造成系統(tǒng)反應(yīng)變慢。后來我們也實(shí)驗(yàn)了一下，在這個(gè)2億的表上統(tǒng)計(jì)一下行數(shù)，即select count(*) from table1，用了1分鐘，內(nèi)存漲了5G左右，磁盤子系統(tǒng)負(fù)荷很大，CPU也突然提高。這說明這種上億的表的操作會非常嚴(yán)重的降低效率。

◆2.整個(gè)服務(wù)器的磁盤分配是這樣的，網(wǎng)站訪問的數(shù)據(jù)庫庫位于磁盤陣列中，而我們的統(tǒng)計(jì)臨時(shí)庫位于D盤中，C和D好像是一個(gè)磁盤組，也就相當(dāng)于是在C盤。我們的數(shù)據(jù)庫的大量磁盤I/O會導(dǎo)致系統(tǒng)的反應(yīng)變慢。因此當(dāng)我的查詢很大的時(shí)候，就會使服務(wù)器整個(gè)系統(tǒng)變慢。

◆3.數(shù)據(jù)庫的數(shù)據(jù)文件的自增長方式為每次1024k，數(shù)據(jù)文件的空間已經(jīng)接近用光，而要發(fā)生增長，而增長空間要求應(yīng)該比較大，所以就會不停的申請?jiān)鲩L，造成磁盤開銷較大。

◆4.操作中涉及到delete操作，會形成大量的日志，而上周擴(kuò)容后，發(fā)現(xiàn)日志文件比以前縮小了，估計(jì)是重建了，昨天的操作會導(dǎo)致日志文件也要不斷增長，也會造成磁盤的負(fù)荷加大。

解決辦法：

針對一：

避免大表操作，所有的操作均可以按省或者時(shí)間分開，這樣無論從時(shí)間或者地域維度，基本上可以將大表拆成30張以上的小表操作，甚至更多。然后再對結(jié)果進(jìn)行合并，應(yīng)該可以避免上述問題。

針對二：

無解決方案，只是建議將我們的數(shù)據(jù)庫也單獨(dú)分到一組磁盤上去，不要跟系統(tǒng)競爭。

針對三：

及時(shí)刪除無用的臨時(shí)數(shù)據(jù)，保障數(shù)據(jù)庫空間，同時(shí)也可以做上空間監(jiān)控，一旦數(shù)據(jù)文件空間發(fā)生增長時(shí)，給DBA一個(gè)預(yù)警郵件，我們收到郵件后可以立即做相應(yīng)處理。

針對四：

日志文件目前已經(jīng)漲得較大，我們執(zhí)行一下截?cái)嗳罩镜膭幼鳎瑢⑷罩疚募目臻g使用保持在一個(gè)較低水平。