今天看到黑大前幾天發了索引破碎的文，順手轉貼上來；

GUID 叢集索引測試 2：索引碎片化分析與資料表虛胖問題
延伸閱讀：GUID Primary Key資料庫避雷守則

PK使用頻率很高，設成叢集索引對效能最有利，故慣例上會設成叢集索引以提升效能。

然而，因為GUID具有不連續的隨機性，即使循序寫入資料，常常後寫的資料GUID排序較前，依叢集索引特性，實體儲存位置應擺在前段，造成每次寫入資料都需挪動調整既有資料造成索引破碎，拖累寫入與查詢效能。

備註：我現在都無腦用 NEWSEQUENTIALID 了，好香好香

avg_fragmentation_in_percent 可視為碎片化的程度。Logical fragmentation 官方翻譯為邏輯片段，我覺得譯成「邏輯碎片」更體切，指的是索引資料分頁邏輯順序與實體順序不一致，邏輯上依索引順序應該連續的資料分頁，被放在不連續的實體位置，如此存取將需要更多 IO 動作，拖慢效能。此值介於 10 到 15 之間時建議做索引重組，大於 15 時應考慮進行索引重建。

avg_page_space_used_in_percent 則是資料分頁存放資料的比率，比例過低將造成空間浪費(本案例的狀況)，代表要走訪更多分頁才能蒐集完所需要資料，勢必影響效能。這個值介於 60 到 75 之間時建議做索引重組，低於 60 時應考慮索引重建。

敝司也有一張每天會有排程拋一卡車資料進去的表，也是使用 GUID 當 PK。DBA 才剛重建完沒兩天，avg_fragmentation_in_percent 就衝破 70

但因為年久失修綁定古蹟，也不怎麼查詢，現在就當成負面教材來宣導(?)，也算是加深印象了

那麼，今天的轉貼就到這邊，明天見～