索引最初生成時
將索引的資料按照b+樹的結構放置在連續的物理頁上，這樣做的目的是通過連續的i/o掃瞄索引頁面獲得最佳的i/o效能。
insert或者update
當更新後的資料內容超過頁面的儲存空間容量時，引擎分使用頁拆分的方法來獲取足夠的空間儲存新增入進來的索引資料。即另外分配乙個新的頁面（注意這上頁面相對於之前的那些頁面是不連續的了），同時將原來頁面的資料移動一半的資料到新頁上來。最終的結果就是打斷了索引頁面的物理連續性，使得i/o操作從連續變成不連續，從而降低了效能。
碎片的產生
索引碎片的產生很大原因是大量的頁拆分的結果。所以碎片到達一定量時，索引就會失去了快速查詢的作用。
避免頁拆分
相應索引找到合適的填充因子。一般是85%,這樣保證每頁上留有15%的空閒空間，但資料變更時，索引資料的擴充套件就會利用預留空間，減少頁拆分的產生。
alter index pk_t_product on dbo.t_product rebuild with(fillfactor = 85);-- 建立索引的時候設定乙個填充因子
填充因子0或100
這兩種情況下的效果是一樣的，即預留空間最少。
填充因子的後果
雖然減少了頁拆分的產生。但會帶來兩種後果：
索引頁儲存空間增大。填充因子越接近於0，所耗費空間越大。
索引頁的增多，造成查詢效率有所降低。
基於上面的兩點，所以最好的做法是：
找到乙個合適的填充因子。比如85%，不能太大也不能太小。
定期重建索引，替代使用填充因子。但重建索引也須要一定的代價
防止頁拆分的設定原則
聚集索引所在鍵值保證是不斷增長的，最好沒有修改資料，採取先刪除後加入的原則。這樣頁拆分是最少的。
大容量的字段分離到另外的表，保證只有刪除和增加的操作。
資料任何可變欄位的修改都可能會引起聚集索引的更新操作。
非聚集索引所在鍵值被修改或新增情況下才會產生非聚集索引內容的增大。
記憶體碎片產生原因
以下是正文 記憶體碎片通常分為內部碎片和外部碎片 1.內部碎片是由於採用固定大小的記憶體分割槽，當乙個程序不能完全使用分給它的固定記憶體區域時就產生了內部碎片，通常內部碎片難以完全避免 2.外部碎片是由於某些未分配的連續記憶體區域太小，以至於不能滿足任意程序的記憶體分配請求，從而不能被程序利用的記憶...
記憶體碎片產生的原因
malloc和free大量使用後回造成記憶體碎片，那麼這種碎片形成的機理是什麼？如果機理是申請的記憶體空間大小 太小 所形成的，那麼申請多大的區域能夠最大限度的避免記憶體碎片呢 這裡的避免不是絕對的避免，只是一種概率 記憶體碎片一般是由於空閒的連續空間比要申請的空間小，導致這些小記憶體塊不能被利用....
MySQL資料碎片的產生
mysql具有相當多不同種類的儲存引擎來實現列表中的資料儲存功能。每當mysql從你的列表中刪除了一行內容，該段空間就會被留空。而在一段時間內的大量刪除操作，會使這種留空的空間變得比儲存列表內容所使用的空間更大。當mysql對資料進行掃瞄時，它掃瞄的物件實際是列表的容量需求上限，也就是資料被寫入的區...