Cevap.

Soru geçmişi:
SQL sorguları başlangıcından itibaren, "ne almak" üzerine tasarlanmış, "nasıl almak" üzerine değil. Veritabanı yönetim sistemi (VYS) optimizatörü, bağlantıların, filtrelemelerin, taramaların ve indekslerin kullanım sırasını belirleyen bir yürütme planı hazırlar.

Problemi:
Yürütme planı hakkında bilgi sahibi olmadan, basit görünen bir sorgunun neden çok yavaş çalıştığını veya karmaşık bir sorgunun neden hızlı çalıştığını açıklamak mümkün değildir. Yanlış bir plan, gereksiz işlemler veya yanlış indeks kullanımı nedeniyle sunucuyu saatlerce kilitleyebilir.

Çözüm:
Analiz araçları; EXPLAIN, EXPLAIN ANALYZE (PostgreSQL), SHOW EXPLAIN (MySQL), Yönetim Stüdyosu Yürütme Planı (SQL Server) gibi talimatları içerir. Bu araçlarla, sorgunun nasıl adım adım yürütüldüğünü, hangi veri miktarının okunduğunu, hangi indeksin kullanıldığını, tüm tablonun tarandığı yerleri ve gecikmelerin nerede meydana geldiğini görebiliriz.

Kod örneği:

EXPLAIN ANALYZE SELECT * FROM orders o JOIN customers c ON o.customer_id = c.id WHERE o.status = 'shipped';

Anahtar özellikler:

Plan, VYS'nin hangi işlemi hangi sırayla gerçekleştirdiğine dair ayrıntılı bir şemayı sunar.
Nerede indeks taraması ve nerede tablo taraması yapıldığını görebilirsiniz.
Sıkışma noktalarını belirleme ve sorgunun yeniden yazılmasının performansa etkisini kontrol etme olanağı sağlar.

Kandırıcı sorular.

İndeks eklemek, sorguyu her zaman hızlandırır mı?

Hayır! İndeks yalnızca filtrelemenin belirli bir alanda döndürülen satır sayısını önemli ölçüde sınırladığı durumlarda yardımcı olur. Eğer çoğu kayıt koşula uyuyorsa, optimizatör indeksi göz ardı edebilir.

Örnek:

-- 'gender' alanı yalnızca iki değer alıyor — indeks yardım etmeyecek
CREATE INDEX idx_gender ON people(gender);
SELECT * FROM people WHERE gender = 'M';

JOIN'deki tablo sırası yürütme sonucuna bağlı mı?

Hayır, nihai veriler aynı olacak, ancak optimizatör, performansı artırmak için bağlantıların yürütme sırasını değiştirebilir. Ancak belirli bir JOIN yazılmışsa veya "JOIN HINT" gibi ipuçları kullanılıyorsa, sıralama yürütme etkinliğini etkileyebilir.

Yürütme planındaki "Estimated rows" ve "Actual rows"'ı analiz etmenin önemi nedir?

Aralarındaki fark, tablo istatistiklerinin güncel olmadığını veya gerçeklerle uyuşmadığını gösterebilir, yani plan optimal değildir — istatistikleri güncellemeniz veya sorgu yapısını yeniden gözden geçirmeniz gerekebilir.

-- PostgreSQL
ANALYZE table_name; -- istatistikleri güncelle

Yaygın hatalar ve antipatiler

Problemler ortaya çıktığında yürütme planı incelenmiyor: "kör" bir şekilde optimizasyon yapmaya çalışıyorlar.
"Hızlanma" amacıyla gereksiz/hedef dışı indeksler eklenmesi, bu da veri değişimlerini yavaşlatıyor.
Tablo istatistikleri güncellenmiyor.
Sorgular, optimizatörün nasıl çalışacağını göz önünde bulundurmadan tasarlanıyor.

Hayattan bir örnek

Olumsuz durum

Bir projede analistler "raporların donmasından" uzun süredir şikayet ettiler. Beş JOIN içeren bir sorgu 25 dakika sürdü. Görüldü ki, büyük bir tablonun tam tarama planı seçilmişti, indeksler yanlış alanlardaydı ve istatistik bir yıl boyunca güncellenmemişti.

Artılar:

Basit bakım, minimum indeks.

Eksiler:

Sorgu yavaş çalışıyordu, insan emek saatleri kayboluyordu.
Kullanıcı memnuniyetsizliği.
Sunucuda yük.

Olumlu durum

Yürütme planını analiz ettik, gerçekten filtreleme yapan bir alana indeks ekledik, istatistikleri güncelledik. Sorgu süresi 20 saniyeye düştü. Sunucu yükünü önemli ölçüde azalttık.