İndeks eklemek sorguyu hızlandırmadıysa, yanlış soruyu sormuşsundur
Yavaş bir sorguya indeks eklemek çoğu zaman işe yarıyor. İşe yaramadığı durumlar ise ilginç olanlar — ve orada öğrendiğin şey, indeksin ne olduğu değil planlayıcının nasıl düşündüğü.
This post is in Turkish.
Bir sorgu yavaşladı, indeks ekledin, hiçbir şey değişmedi. Bu noktada çoğu kişi ikinci bir indeks ekliyor. Doğru hamle, veritabanına ne yaptığını sormak.
Planlayıcı bir indeksi kullanmıyorsa bunun bir sebebi var, ve o sebebi bilmeden eklenen her indeks yalnızca yazma maliyetini artırıyor.
Planı okumak
Her şeyden önce sorgu planına bakmak gerekiyor — tahminle değil, gerçek çalışma sayılarıyla.
Orada aranacak iki şey var. Birincisi tarama tipi: bütün tabloyu mu geziyor, indeksten mi gidiyor. İkincisi ve daha önemlisi, planlayıcının beklediği satır sayısı ile gerçekte dönen satır sayısı arasındaki fark.
Bu iki sayı birbirinden çok uzaksa, sorun indeks değil istatistik. Planlayıcı yanlış tahmin ettiği için yanlış plan seçiyor. Bu durumda indeks eklemek değil, istatistikleri güncellemek veya örnekleme oranını artırmak gerekiyor.
Kolon sırası bir detay değil
Çok kolonlu indekste sıra, indeksin hangi sorgulara yarayacağını belirliyor.
Kabaca kural şu: eşitlik karşılaştırması yapılan kolonlar önce, aralık karşılaştırması yapılan kolon sonra. Aralık koşulu olan bir kolondan sonraki kolonlar, indeksin filtreleme gücünü kaybediyor.
Ve sıralama da bu işin parçası. Doğru sırayla tanımlanmış bir indeks, sıralama adımını tamamen ortadan kaldırıyor — özellikle "son elli kayıt" tipi sorgularda fark büyük.
Bir indeks, sorguyu hızlandırmıyorsa maliyet; hızlandırıyorsa yatırım. Aradaki farkı sadece plan söylüyor.
İndeksin görünmez maliyeti
Her indeks, her yazma işleminde güncelleniyor.
Ekleme ağırlıklı bir tabloda — mesaj, günlük, stok hareketi — beş indeks, yazma hızını doğrudan etkiliyor. Ve bu maliyet sorgu planında görünmüyor, çünkü yavaşlayan şey okuma değil.
İki veritabanı yazısında anlattığım ayrımın bir sebebi de buydu: sürekli ekleme yapılan bir tabloda indeks yönetimi kendi başına bir iş hâline geliyor.
Buna karşılık, hiç kullanılmayan indeksler de birikiyor. Veritabanı hangi indekslerin kullanıldığını sayıyor — o sayaca bakıp aylardır hiç dokunulmamış indeksleri silmek, çoğu projede kolay bir kazanç.
Kısmi ve ifade indeksleri
En çok işe yarayan iki araç en az bilinenler.
Kısmi indeks, tablonun sadece bir kısmını kapsıyor. Bir milyon siparişin içinde yalnızca beklemedekiler sorgulanıyorsa, indeksi sadece o satırlar için kurmak hem küçük hem hızlı — ve yazma maliyeti de sadece o satırlarda oluşuyor.
İfade indeksi ise sorgunun kolona doğrudan değil bir dönüşümün sonucuna baktığı durumlarda gerekiyor. Kolonu bir fonksiyonla sarmalayan bir koşul, normal indeksi devre dışı bırakıyor — çünkü indekste duran şey ham değer, aranansa dönüşmüş değer.
Politikaların içi de sorgu
Son ve kolay atlanan nokta: satır seviyesi politikalar her satır için değerlendiriliyor.
Politikanın içinde bir alt sorgu varsa, bin satırlık bir listede bin kez çalışabiliyor. Ve bu maliyet, senin yazdığın sorgunun planında ilk bakışta görünmüyor.
RLS yazısında söylediğim şeyin somut hâli bu: politikada kullandığın her alan indeksli olmak zorunda. Yoksa güvenlik katmanın, performans probleminin kaynağı oluyor — ve bunu fark etmenin genelde tek yolu, üretimde birdenbire yavaşlayan bir sayfa.