İndeks bakımı için bütün indeksleri her gece rebuild etmek yaygın fakat pahalı bir alışkanlıktır. İşlem transaction logu büyütür, IO tüketir, replikasyon trafiği oluşturur ve bazı sürümlerde uzun kilitlere yol açabilir. Üstelik küçük indekslerde yüksek fragmentation yüzdesi performans açısından anlamsız olabilir. Bakım kararı gerçek iş yüküne dayanmalıdır.

Fragmentation tek başına yeterli değildir

Sayfa sayısı düşük bir indeks zaten belleğe kolayca sığar. Büyük indekslerde page density düşüşü daha fazla sayfanın okunmasına neden olabilir. Sequential key eklemeleri, rastgele GUID kullanımı ve yanlış fill factor farklı davranışlar üretir. İstatistik güncelliği de optimizer planları için çoğu zaman fiziksel fragmentation değerinden daha önemlidir.

Bakım adayı sorgusu

Aşağıdaki sorgu yalnızca anlamlı büyüklükteki indeksleri listeler. Eşikler sabit reçete değildir; sunucunun bakım penceresi ve ölçülen sorgu etkisine göre ayarlanmalıdır.

SELECT
    OBJECT_SCHEMA_NAME(ps.object_id) AS SchemaName,
    OBJECT_NAME(ps.object_id) AS TableName,
    i.name AS IndexName,
    ps.page_count,
    ps.avg_fragmentation_in_percent,
    ps.avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') ps
JOIN sys.indexes i
  ON i.object_id = ps.object_id AND i.index_id = ps.index_id
WHERE ps.page_count >= 1000
ORDER BY ps.page_count DESC;

Sonuç listesini Query Store ve kullanım DMV'leriyle birleştirin. Hiç okunmayan fakat yoğun güncellenen bir indeks için rebuild yapmak yerine indeksin gerekliliğini sorgulamak daha değerlidir. Bakım sonrasında süre, log büyümesi ve sorgu IO değişimini kaydedin.

Önerilen yaklaşım

1. Küçük indeksleri bakım kapsamı dışında bırakacak minimum page_count değeri belirleyin.
2. Yoğun kullanılan büyük indekslerde fragmentation ve page density değerlerini birlikte değerlendirin.
3. Reorganize, online rebuild veya hiçbir işlem seçeneklerini bakım penceresine göre seçin.
4. İstatistik güncellemesini indeks rebuild işleminden bağımsız planlayın.
5. Bakım süresi, log kullanımı ve sorgu performansını zaman serisi olarak izleyin.

Sık yapılan hatalar

• Yüzde 30 üzerindeki her indeksi koşulsuz rebuild etmek.
• Availability Group veya log shipping üzerindeki ek trafik etkisini hesaba katmamak.
• Yanlış fill factor vererek sayfa bölünmesini azaltırken okuma maliyetini gereksiz artırmak.

Sonuç

İyi indeks bakımı takvim tabanlı değil kanıt tabanlıdır. Önce hangi sorguların ve indekslerin gerçekten önemli olduğunu belirleyin; ardından en az maliyetli müdahaleyi seçin. Bazı geceler en doğru bakım işlemi hiçbir şey yapmamaktır. Ölçüm, otomatik bir rebuild döngüsünden daha güvenli ve daha ekonomiktir.