SQL Server數據庫自身優化(2)

　　[AVNote] [varchar](300) NULL,

　　[bb] [int] IDENTITY(1,1)

　　) ON [myRangePS2](bb); –注意這里使用[myRangePS2]架構，根據bb分區

　　2.3.4查詢表分區

　　SELECT *, $PARTITION.[myRangePF2](bb) FROM dbo.AVCache

　　這樣就可以清楚的看到表數據是如何分區的了

　　2.3.5創建索引分區

　　優化③：分布式數據庫設計

　　分布式數據庫系統是在集中式數據庫系統的基礎上發展起來的，理解起來也很簡單，就是將整體的數據庫分開，分布到各個地方，就其本質而言，分布式數據庫系統分為兩種：1.數據在邏輯上是統一的，而在物理上卻是分散的，一個分布式數據庫在邏輯上是一個統一的整體，在物理上則是分別存儲在不同的物理節點上，我們通常說的分布式數據庫都是這種2.邏輯是分布的，物理上也是分布的，這種也成聯邦式分布數據庫，由于組成聯邦的各個子數據庫系統是相對“自治”的，這種系統可以容納多種不同用途的、差異較大的數據庫，比較適宜于大范圍內數據庫的集成。

　　分布式數據庫較為復雜，在此不作詳細的使用和說明，只是舉例說明一下，現在分布式數據庫多用于用戶分區性較強的系統中，如果一個全國連鎖店，一般設計為每個分店都有自己的銷售和庫存等信息，總部則需要有員工，供應商，分店信息等數據庫，這類型的分店數據庫可以完全一致，很多系統也可能導致不一致，這樣，各個連鎖店數據存儲在本地，從而提高了影響速度，降低了通信費用，而且數據分布在不同場地，且存有多個副本，即使個別場地發生故障，不致引起整個系統的癱瘓。 但是他也帶來很多問題，如：數據一致性問題、數據遠程傳遞的實現、通信開銷的降低等，這使得分布式數據庫系統的開發變得較為復雜，只是讓大家明白其原理，具體的使用方式就不做詳細的介紹了。

　　優化④：整理數據庫碎片

　　如果你的表已經創建好了索引，但性能卻仍然不好，那很可能是產生了索引碎片，你需要進行索引碎片整理。

　　什么是索引碎片?

　　由于表上有過度地插入、修改和刪除操作，索引頁被分成多塊就形成了索引碎片，如果索引碎片嚴重，那掃描索引的時間就會變長，甚至導致索引不可用，因此數據檢索操作就慢下來了。

　　如何知道是否發生了索引碎片?

　　在SQLServer數據庫，通過DBCC ShowContig或DBCC ShowContig(表名)檢查索引碎片情況，指導我們對其進行定時重建整理。

　　通過對掃描密度(過低)，掃描碎片(過高)的結果分析，判定是否需要索引重建，主要看如下兩個：

　　Scan Density [Best Count:Actual Count]-掃描密度[最佳值:實際值]：DBCC SHOWCONTIG返回最有用的一個百分比。這是擴展盤區的最佳值和實際值的比率。該百分比應該盡可能靠近100%。低了則說明有外部碎片。

　　Logical Scan Fragmentation-邏輯掃描碎片：無序頁的百分比。該百分比應該在0%到10%之間，高了則說明有外部碎片。

　　解決方式：

　　一是利用DBCC INDEXDEFRAG整理索引碎片

　　二是利用DBCC DBREINDEX重建索引。

　　兩者區別調用微軟的原話如下：

　　DBCC INDEXDEFRAG 命令是聯機操作，所以索引只有在該命令正在運行時才可用，而且可以在不丟失已完成工作的情況下中斷該操作。這種方法的缺點是在重新組織數據方面沒有聚集索引的除去/重新創建操作有效。

　　重新創建聚集索引將對數據進行重新組織，其結果是使數據頁填滿。填滿程度可以使用 FILLFACTOR 選項進行配置。這種方法的缺點是索引在除去/重新創建周期內為脫機狀態，并且操作屬原子級。如果中斷索引創建，則不會重新創建該索引。也就是說，要想獲得好的效果，還是得用重建索引，所以決定重建索引。

原文轉自：http://www.anti-gravitydesign.com