Phân mảnh index trong database

Phân mảnh logical (hay là external fragmentation)
- Xảy ra khi page tiếp theo không cùng thứ tự lưu trữ vật lý
- Không thể scan theo range vì phải đọc "nhảy cóc"
- Tuy nhiên, vấn đề này không quá nghiêm trọng
Phân mảnh vật lý (hay internal fragmentation)
- Xảy ra khi page vẫn còn chỗ trống nhưng không thể lưu trữ được vào.
- Điều này khiến cho dung lượng lưu trữ tăng lên rất lớn, giảm khả năng đọc ghi do phải đọc trực tiếp từ đĩa nhiều

Xảy ra khi 1 record chèn vào 1 page cụ thể nhưng không còn chỗ trống để insert thêm.
Điều này khiến cho page phải "chia" (split) để có chỗ trống lưu bản ghi mới vào (hình 1)

Hiện tượng split page

khi ta chèn bản ghi có key = 5 vào table, nó cần chèn vào page 1. Do page 1 đã đầy nên page 1 cần chia làm 2 page là page 1 và 3. Điều này gây ra 2 tình trạng, thứ nhất là page 1 và 3 về mặt logic là theo thứ tự, nhưng về mặt vật lí thì không, nếu khi quét dữ liệu thì phải đọc theo kiểu "nhảy cóc", tốn thời gian hơn so với đọc tuần tự. TÌnh trạng thứ 2 là khi page bị tách làm 2 như thế kia, vô hình chung để ra những "khoảng trống" không thể dùng được gây tốn bộ nhớ.

Ok giờ ta đã hiểu về phân mảnh, nguyên nhân gây phân mảnh. Chú ý 1 điều là phân mảnh không thể tránh khỏi được, tuy nhiên nên tìm cách hạn chế phân mảnh dữ liệu
Fill factor là 1 chỉ số được config để limit số record trong 1 page. ví dụ 1 page có tối đa 10 bản ghi, với fill factor là 80% thì khi insert chỉ tối đa được 8 bản ghi.
Fill factor 100 (full page) ko phù hợp cho các hệ thống OLTP do có update dữ liệu nhiều

Nên cân bằng về việc tần suất tình trạng page split diễn ra và tần suất rebuild index
Nếu hay rebuild index thì có thể để fill factor cao
Nếu dùng random insert (như uuid vào cluster index), thì có thể để fill factor thấp hơn
Nên chọn 1 giá trị rồi monitor dần, thông thường ở lần đầu có thể chọn fill factor là 70%

Index phân mảnh là một trong những nguyên nhân gây chậm hệ thống, dù database có rất ít bản ghi.