轉帖|其它|編輯:郝浩|2011-06-01 14:11:29.000|閱讀 678 次
概述:這段時間,在SQL Server的生產環境中嘗試了不同方式的表分區,積累了一些這方面的經驗,這里就表分區的一些注意事項做些記錄。
# 界面/圖表報表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
一、表分區文章索引
二、目的
這段時間,在SQL Server的生產環境中嘗試了不同方式的表分區,積累了一些這方面的經驗,這里就表分區的一些注意事項做些記錄。
三、注意事項
1、表分區的邊界值問題,在使用Left和Right的時候需要注意,特別是在時間分割上需要特別注意,通常情況下,以00:00:00.000是最可靠的,這種分割就需要使用到Right,如果是Left的話就需要設置為23:59:59.997;
2、 對于分區值的第一個值,符合這個值之前的數值都會給分配到第一個分區中,而使用Left和Right的區別就是這個分區值會被分配到第一個分區還是第二個分區而已;
3、在SQL Server 2005 中的分區表和索引也提到在時間分區上的例子,RANGE RIGHT FOR VALUES ('20001001 00:00:00.000', '20010101 00:00:00.000', '20010401 00:00:00.000', '20010701 00:00:00.000'),更加簡便的形式就是RANGE RIGHT FOR VALUES ('20001001', '20010101', '20010401', '20010701'),完全撇開了時分秒的問題了。
4、通常情況下,我們會以一個表Id(int),并且是自增作為分區字段,這樣分區的好處就是很容易區分歷史數據了(假如你的歷史數據是以插入到表的時間來區別的話),而且對分區的操作隔離也是最明顯的。
5、當以Id作為分區函數值并不能滿足你的需求的時候,你可能需要考慮不一樣的東西了,因為在創建Id為主鍵的時候,默認的情況下就是為這個主鍵創建為聚集索引的,所以以Id為分區字段的話,Id自增,就會順序的被放到遞增的分區文件中。這里假如你想以分類標識ClassId作為分區的話,那么你有幾種選擇,一個就是把Id+ClassId作為非聚集的主鍵(PRIMARY KEY NONCLUSTERED),創建ClassId為聚集索引(CLUSTERED),這樣就可以以ClassId作為分區字段了;另外一個選擇就是:Id+ClassId作為聚集的主鍵(PRIMARY KEY CLUSTERED),這樣就不用另外創建一個索引了。
6、對聚集索引進行分區時,聚集鍵必須包含分區依據列。對非唯一的聚集索引進行分區時,如果未在聚集鍵中明確指定分區依據列,默認情況下 SQL Server 將在聚集索引鍵列表中添加分區依據列。如果聚集索引是唯一的,則必須明確指定聚集索引鍵包含分區依據列。對唯一的非聚集索引進行分區時,索引鍵必須包含分區依據列。對非唯一的非聚集索引進行分區時,默認情況下 SQL Server 將分區依據列添加為索引的非鍵(包含性)列,以確保索引與基表對齊。如果索引中已經存在分區依據列,SQL Server 將不會向索引中添加分區依據列。
7、如果你需要在你的分區上創建全文索引,那么你創建分區的時候就需要注意了,因為全文索引需要唯一索引的支持,而且這個唯一索引不能是復合索引,只能是單個字段的唯一索引。這個索引的要求:“unique, single-column, non-nullable index”。
8、如果我們的分區值是隨著時間的變化而增加的話,那么我們在設置表分區之后,系統跑了一段時間之后,那么最后一個分區占用的空間就會越來越大,除非你在創建分區的時候已經確認了這些分區值不會再增加了,在MSDN的文檔中:SQL Server 2005 中的分區表和索引,里面提到的月份表分區、地區分區這些固定分區值,這并沒有很好的表達在生產環境中所面臨的分區值在不斷增長的問題。所以這里就針對這個問題做了一個Job,這個Job可以動態、自動化的完成刪除分區(交換分區),修改分區函數、分區方案等操作。
9、在MSDN自動化分區的前驅:SQL2005PartitioningScripts.exe,里面有些是值得參考的,但是開發一個適合自己業務需求的自動化分區也是必要的.
本站文章除注明轉載外,均為本站原創或翻譯。歡迎任何形式的轉載,但請務必注明出處、不得修改原文相關鏈接,如果存在內容上的異議請郵件反饋至chenjj@fc6vip.cn
文章轉載自:網絡轉載