我們有一些客戶的數(shù)據(jù)庫是巨量數(shù)據(jù)，特別是用到生產(chǎn)管理的模塊，千萬行甚至億行記錄都不足為奇。如此情況下，數(shù)據(jù)庫運行速度將受到嚴(yán)重影響，打開一個賬表半小時甚至兩小時，做一個計劃要兩天兩夜，客戶抱怨不斷，服務(wù)人員焦頭爛額，總不能叫客戶都去買大型計算機(jī)吧。
其實是有辦法可以大大提升數(shù)據(jù)庫運行效率的，這要求我們的服務(wù)人員要學(xué)會數(shù)據(jù)庫日常維護(hù)的高級技巧，而且是必須學(xué)會。
下面是數(shù)據(jù)庫效率提升技巧的全面內(nèi)容，建議所有服務(wù)人員自行練習(xí)并用在實際工作中，要求熟練掌握。
技巧一：重建索引效率提升指數(shù)：高
特點：一二三買單，灰常的快，一下就弄完可以走人了。
案例：某超市T1商貿(mào)寶 百萬行級數(shù)據(jù)，原速度五秒，重建索引后兩秒不到，速度提升近一倍。不要小看這幾秒，對超市來講，那意味著不必要排長隊。
由于數(shù)據(jù)庫日常寫操作頻繁，索引的工作效率會越來越低，速度自然大受影響，很多客戶會有這種感覺，前半年還非常快，后半年就受不了了。剛剛到年底，正好是出報告、查資料的年關(guān)，偏偏軟件慢得要命，服務(wù)人員也別想有好日子過，陪著加班吧，就算解決不了問題，也讓人家心理舒服點。這樣的日子可以過去了。
命令1：DBCC DBREINDEX (表名稱,"",70) ---針對主要影響速度的表，一般如rdrecords、salebillvouchs、pp_mrpdetails、pp_rmrpdetails
說明：只對主要表操作，影響速度的當(dāng)然是這幾個大表，速度解決問題，也不影響客戶使用
命令2：exec sp_msforeachtable "DBCC DBREINDEX(""?"")" ---數(shù)據(jù)庫所有表重建索引
說明：不太建議，除非太咸了
特別指出，重建索引前必須斷網(wǎng)，以保證所有客戶端無人在操作軟件，你懂的
技巧二：表分區(qū) 效率提升指數(shù)：超高
特點：慢工出快活。硬盤越多，它就越快，所有硬盤一起轉(zhuǎn)當(dāng)然快；CPU越多，它就更快，sqlserver的引擎對這個有優(yōu)化設(shè)計；設(shè)計得越合理，它就灰常滴快，例如歷史數(shù)據(jù)按年存放，因為你一般不用嘛，那數(shù)據(jù)庫只對你要操作的部分分區(qū)檢索，自然飛快。
還有，必須得是sql2005及以上版本，人家買的ERP你還裝sql2000，去死吧。
案例：NC、U8 10.0，是的，它們用的就是表分區(qū)，所以數(shù)據(jù)越海，速度也越Hi
沒有做表分區(qū)之前，客戶是痛苦的，你也得痛苦，因為你不明白幾萬元的服務(wù)器怎么就玩不轉(zhuǎn)一個T6，但NC這么海卻可以在寬帶上溜溜的跑？U8 10.0還不分年度褲呢，咱一個年度還用爬的？如果我說可以提升五倍甚至更高的速度，你信不信？反正我是信了。
真的。
這個有點點難，因為要求有更多的數(shù)據(jù)庫知識，不過初中生的水平也夠用了，來吧。
1.為數(shù)據(jù)庫建個文件組（可以建多個），最好是存放于不同磁盤上。這樣效率得以最大化，想一想吧，我們查一個年度所有收發(fā)記錄，三個硬盤一起轉(zhuǎn)，是不是原來速度的三倍？
ALTER DATABASE 數(shù)據(jù)庫名 ADD FILEGROUP 文件組名
2.一個文件組可放置多個文件，下面，只為一個文件組分配一個文件，類推吧。
ALTER DATABASE 數(shù)據(jù)庫名 ADD FILE (NAME = N"文件組名", FILENAME = N"存放路徑",SIZE = 5MB , FILEGROWTH = 10% ) TO FILEGROUP 文件組名
3.創(chuàng)建分區(qū)函數(shù)。這個函數(shù)是本文件組專有的，再建其它的文件組還得再搞一個。主要是設(shè)定，包括預(yù)設(shè)現(xiàn)有的數(shù)據(jù)從哪里開始水平分割，比如我們假設(shè)U8 10.0的上一年度最后一行rdrecords記錄的Id是5000000，那么就可以設(shè)定這個值，這以內(nèi)的記錄會切割保存到第一個分區(qū)中。
CREATE PARTITION FUNCTION [函數(shù)名] (int) AS RANGE LEFT FOR VALUES (5000000,8274249,12000000)
此句表示，分三個區(qū)存放原先的數(shù)據(jù)
4.將分區(qū)函數(shù)綁定到分區(qū)架構(gòu)上
CREATE PARTITION SCHEME [架構(gòu)名]
AS PARTITION [函數(shù)名]
TO ([PRIMARY],[文件組名],[PRIMARY],[文件組名],[PRIMARY],[文件組名])
5.刪除表的主鍵，必須刪除，表擔(dān)心，主鍵可以再建的
ALTER TABLE 數(shù)據(jù)表名稱 DROP CONSTRAINT [主鍵]
6.刪除聚集索引，如果有的話，我還沒找到命令，現(xiàn)在是手動刪除的
7.開始做表分區(qū)
ALTER TABLE 數(shù)據(jù)表名稱 add CONSTRAINT [主鍵] PRIMARY KEY CLUSTERED (主鍵字段名)
ON [SHEME_rdrec](主鍵字段名)
你看，這不是恢復(fù)了主鍵嗎
不過還是得手動恢復(fù)原來的聚集索引，這個我再查查語句吧
特別提出：數(shù)據(jù)庫收縮并不能提高數(shù)據(jù)庫的讀取效率，正相反，它反而更慢了。原因，是收縮后數(shù)據(jù)庫內(nèi)部的數(shù)據(jù)存儲發(fā)生位移，也就是索引變得更低效。
這種情況下，必須再做一次索引重建，但我發(fā)現(xiàn)似乎只要收縮了以后，數(shù)據(jù)庫都慢，重建索引也恢復(fù)不到原來的速度，一下想不明白道理，而且做的測試次數(shù)也有限。
(轉(zhuǎn)帖于:http://bbs.iufida.com/thread-174625-1-1.html)
</script>