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