這樣就可以清楚的看到表數(shù)據(jù)是如何分區(qū)的了

2.3.5創(chuàng)建索引分區(qū)

優(yōu)化③：分布式數(shù)據(jù)庫(kù)設(shè)計(jì)

分布式數(shù)據(jù)庫(kù)系統(tǒng)是在集中式數(shù)據(jù)庫(kù)系統(tǒng)的基礎(chǔ)上發(fā)展起來(lái)的，理解起來(lái)也很簡(jiǎn)單，就是將整體的數(shù)據(jù)庫(kù)分開(kāi)，分布到各個(gè)地方，就其本質(zhì)而言，分布式數(shù)據(jù)庫(kù)系統(tǒng)分為兩種：1.數(shù)據(jù)在邏輯上是統(tǒng)一的，而在物理上卻是分散的，一個(gè)分布式數(shù)據(jù)庫(kù)在邏輯上是一個(gè)統(tǒng)一的整體，在物理上則是分別存儲(chǔ)在不同的物理節(jié)點(diǎn)上，我們通常說(shuō)的分布式數(shù)據(jù)庫(kù)都是這種2.邏輯是分布的，物理上也是分布的，這種也成聯(lián)邦式分布數(shù)據(jù)庫(kù)，由于組成聯(lián)邦的各個(gè)子數(shù)據(jù)庫(kù)系統(tǒng)是相對(duì)“自治” 的，這種系統(tǒng)可以容納多種不同用途的、差異較大的數(shù)據(jù)庫(kù)，比較適宜于大范圍內(nèi)數(shù)據(jù)庫(kù)的集成。

分布式數(shù)據(jù)庫(kù)較為復(fù)雜，在此不作詳細(xì)的使用和說(shuō)明，只是舉例說(shuō)明一下，現(xiàn)在分布式數(shù)據(jù)庫(kù)多用于用戶(hù)分區(qū)性較強(qiáng)的系統(tǒng)中，如果一個(gè)全國(guó)連鎖店，一般設(shè)計(jì)為每個(gè)分店都有自己的銷(xiāo)售和庫(kù)存等信息，總部則需要有員工，供應(yīng)商，分店信息等數(shù)據(jù)庫(kù)，這類(lèi)型的分店數(shù)據(jù)庫(kù)可以完全一致，很多系統(tǒng)也可能導(dǎo)致不一致，這樣，各個(gè)連鎖店數(shù)據(jù)存儲(chǔ)在本地，從而提高了影響速度，降低了通信費(fèi)用，而且數(shù)據(jù)分布在不同場(chǎng)地，且存有多個(gè)副本，即使個(gè)別場(chǎng)地發(fā)生故障，不致引起整個(gè)系統(tǒng)的癱瘓。 但是他也帶來(lái)很多問(wèn)題，如：數(shù)據(jù)一致性問(wèn)題、數(shù)據(jù)遠(yuǎn)程傳遞的實(shí)現(xiàn)、通信開(kāi)銷(xiāo)的降低等，這使得分布式數(shù)據(jù)庫(kù)系統(tǒng)的開(kāi)發(fā)變得較為復(fù)雜，只是讓大家明白其原理，具體的使用方式就不做詳細(xì)的介紹了。 

優(yōu)化④：整理數(shù)據(jù)庫(kù)碎片

如果你的表已經(jīng)創(chuàng)建好了索引，但性能卻仍然不好，那很可能是產(chǎn)生了索引碎片，你需要進(jìn)行索引碎片整理。

什么是索引碎片?

由于表上有過(guò)度地插入、修改和刪除操作，索引頁(yè)被分成多塊就形成了索引碎片，如果索引碎片嚴(yán)重，那掃描索引的時(shí)間就會(huì)變長(zhǎng)，甚至導(dǎo)致索引不可用，因此數(shù)據(jù)檢索操作就慢下來(lái)了。

如何知道是否發(fā)生了索引碎片?

在SQLServer數(shù)據(jù)庫(kù)，通過(guò)DBCC ShowContig或DBCC ShowContig(表名)檢查索引碎片情況，指導(dǎo)我們對(duì)其進(jìn)行定時(shí)重建整理。 

通過(guò)對(duì)掃描密度（過(guò)低），掃描碎片（過(guò)高）的結(jié)果分析，判定是否需要索引重建，主要看如下兩個(gè)：
Scan Density [Best Count:Actual Count]-掃描密度［最佳值:實(shí)際值］：DBCC SHOWCONTIG返回最有用的一個(gè)百分比。這是擴(kuò)展盤(pán)區(qū)的最佳值和實(shí)際值的比率。該百分比應(yīng)該盡可能靠近100％。低了則說(shuō)明有外部碎片。

Logical Scan Fragmentation-邏輯掃描碎片：無(wú)序頁(yè)的百分比。該百分比應(yīng)該在0％到10％之間，高了則說(shuō)明有外部碎片。 

解決方式：

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

二是利用DBCC DBREINDEX重建索引。

兩者區(qū)別調(diào)用微軟的原話(huà)如下：

DBCC INDEXDEFRAG 命令是聯(lián)機(jī)操作，所以索引只有在該命令正在運(yùn)行時(shí)才可用，而且可以在不丟失已完成工作的情況下中斷該操作。這種方法的缺點(diǎn)是在重新組織數(shù)據(jù)方面沒(méi)有聚集索引的除去/重新創(chuàng)建操作有效。

重新創(chuàng)建聚集索引將對(duì)數(shù)據(jù)進(jìn)行重新組織，其結(jié)果是使數(shù)據(jù)頁(yè)填滿(mǎn)。填滿(mǎn)程度可以使用 FILLFACTOR 選項(xiàng)進(jìn)行配置。這種方法的缺點(diǎn)是索引在除去/重新創(chuàng)建周期內(nèi)為脫機(jī)狀態(tài)，并且操作屬原子級(jí)。如果中斷索引創(chuàng)建，則不會(huì)重新創(chuàng)建該索引。也就是說(shuō)，要想獲得好的效果，還是得用重建索引，所以決定重建索引。

hanrui