Data & SQL 6 dk okuma

SQL Server Index Stratejileri: 10 Pratik İpucu ile Performansı Artırın

6 dk okuma

Giriş

SQL Server index stratejileri, yoğun çalışan veritabanlarında performansı iyileştirmenin en etkili yollarından biridir. Ancak her kolona index eklemek çözüm değildir. Yanlış tasarlanmış indexler INSERT, UPDATE ve DELETE işlemlerini yavaşlatabilir, depolama tüketimini artırabilir ve optimizerın gereksiz seçenekler arasında karar vermesine neden olabilir. Bu rehberde SQL Server index stratejileri konusunu sorgu planı, seçicilik, INCLUDE kolonları, istatistikler ve bakım perspektifinden ele alıyoruz.

İçindekiler

  • Önce yavaş sorguyu ölçün
  • Clustered index’i bilinçli seçin
  • Nonclustered index’i sorgu desenine göre tasarlayın
  • SQL Server index stratejileri için kolon sırası
  • INCLUDE ile covering index oluşturun
  • Fazla index’ten kaçının
  • İstatistikleri güncel tutun
  • Fragmentation’ı doğru yorumlayın
  • Execution Plan ve Query Store kullanın
  • Index değişikliklerini test ederek yayınlayın

1. Önce Yavaş Sorguyu Ölçün

Index eklemeden önce darboğazın gerçekten veri erişiminden kaynaklandığını doğrulayın. Actual Execution Plan, SET STATISTICS IO, SET STATISTICS TIME ve Query Store; hangi tabloda scan oluştuğunu, kaç logical read yapıldığını ve sorgunun CPU ile elapsed time davranışını görmenize yardım eder. Ölçüm olmadan eklenen index, gerçek problemi çözmeden yeni bakım maliyeti oluşturabilir.

2. Clustered Index’i Bilinçli Seçin

Clustered index tablonun satırlarını anahtar sırasına göre organize eder ve leaf level’da gerçek veri sayfalarını içerir. Dar, benzersiz, mümkün olduğunca artan ve sık değişmeyen bir anahtar çoğu OLTP senaryosunda iyi başlangıç noktasıdır. Çok geniş veya sürekli değişen clustered key, diğer nonclustered indexlerde de taşındığı için toplam depolama ve yazma maliyetini büyütebilir.

3. Nonclustered Index’i Sorgu Desenine Göre Tasarlayın

Nonclustered index kararını tablo şemasından çok gerçek sorgular belirlemelidir. WHERE, JOIN, ORDER BY ve GROUP BY ifadelerinde sık kullanılan kolonları inceleyin. Bir indexin değerini yalnızca tek sorguda hız kazandırmasıyla değil, sistem genelindeki okuma-yazma dengesiyle değerlendirin.

4. SQL Server Index Stratejileri İçin Kolon Sırası

SQL Server index stratejileri uygulanırken composite index içindeki kolon sırası kritik önemdedir. Equality predicate’lerde kullanılan ve seçiciliği yüksek kolonlar çoğu durumda anahtarın ön tarafında avantaj sağlar; ardından range veya sıralama ihtiyacı gelen kolonlar değerlendirilebilir. Ancak tek bir evrensel sıra yoktur: execution plan ve gerçek workload ile doğrulama yapılmalıdır.

5. INCLUDE ile Covering Index Oluşturun

Bir sorgunun filtreleme için kullanmadığı fakat SELECT çıktısında ihtiyaç duyduğu kolonları index key’e eklemek yerine INCLUDE bölümünde tutmak faydalı olabilir. Böylece key yapısını gereksiz yere genişletmeden sorgunun ihtiyaç duyduğu kolonların tamamı index üzerinden karşılanabilir ve Key Lookup sayısı azaltılabilir. INCLUDE kullanımında satır genişliği ve toplam index boyutu yine takip edilmelidir.

6. Fazla Index’ten Kaçının

Her index okuma performansına potansiyel katkı sağlarken yazma işlemlerine ek yük getirir. Aynı başlangıç kolonlarına sahip, büyük ölçüde örtüşen indexleri düzenli olarak inceleyin. Kullanım istatistikleri fikir verir; ancak yalnızca kısa süreli kullanım verisine bakarak kritik bir indexi silmeyin. İş yükünün günlük, haftalık ve aylık döngülerini hesaba katın.

7. İstatistikleri Güncel Tutun

SQL Server optimizer cardinality tahmini yaparken istatistiklerden yararlanır. Veri dağılımı ciddi biçimde değiştiğinde eski istatistikler doğru index mevcut olsa bile kötü plan seçimine yol açabilir. AUTO_UPDATE_STATISTICS çoğu sistem için iyi temel sağlar; yüksek hacimli veya özel dağılımlı tablolarda kontrollü manuel güncelleme stratejileri gerekebilir.

8. Fragmentation’ı Doğru Yorumlayın

Fragmentation tek başına performans problemi anlamına gelmez. Küçük indexlerde yüksek yüzde değerleri pratikte önemsiz olabilir. Reorganize veya rebuild kararı verirken index boyutu, page count, storage tipi, bakım penceresi ve gerçek sorgu performansı birlikte değerlendirilmelidir. Körlemesine her gece tüm indexleri rebuild etmek gereksiz I/O ve log üretimine neden olabilir.

9. Execution Plan ve Query Store Kullanın

Execution Plan; seek, scan, lookup, sort, join ve memory grant gibi davranışları görünür kılar. Query Store ise sorgu performansının zaman içindeki değişimini, plan geçmişini ve regresyonları takip etmeyi kolaylaştırır. Index değişikliği öncesi ve sonrası aynı sorguların duration, CPU ve logical reads değerlerini karşılaştırmak, değişikliğin gerçek etkisini ortaya koyar.

10. Index Değişikliklerini Test Ederek Yayınlayın

Yeni indexi doğrudan üretime eklemek yerine mümkünse üretime yakın veri hacmiyle test edin. Build süresini, transaction log büyümesini, disk alanını ve yazma gecikmesini izleyin. Büyük tablolarda desteklenen sürüm ve edition özelliklerine göre online veya resumable operasyonları değerlendirin. CI/CD veya DBA değişiklik sürecinde index DDL scriptlerini versiyonlamak geri dönüş ve denetim açısından faydalıdır.

Sonuç

SQL Server index stratejileri, tek seferlik bir tuning işlemi değil; ölçüm, tasarım, doğrulama ve bakım döngüsüdür. En iyi index yalnızca bir SELECT sorgusunu hızlandıran değil, sistemin toplam workloadında sürdürülebilir kazanç sağlayan indextir. Query Store ve execution plan verileriyle kararları ölçülebilir hale getirmek, gereksiz index sayısını sınırlamak ve istatistikleri sağlıklı tutmak uzun vadede daha öngörülebilir SQL Server performansı sağlar.

Araştırma Kaynakları

Paylaş