Yavaş Sorguları Fark Etme ve Düzeltme

Bu, mülakatın kapsamlı sorusudur: mülakat yapan kişi size yavaş bir sorgu ve bir EXPLAIN ANALYZE planı verir ve bunu tanılamanızı ister. Ölçülen şey ezberlenmiş püf noktaları değil, bir yöntemdir.

Güçlü bir yanıt, kontrol listesini sesli biçimde izler: ölçün, planı okuyun, baskın maliyeti bulun, bir varsayım oluşturun, bir çözüm önerin ve doğrulayın. Bu ders, bu kontrol listesini adım adım oluşturur.

Sistematik kalın ve akıl yürütmenizi açıklayın; kıdemli düzey değerlendirmesini kazandıran şey budur.

Yalnızca SQL'e bakarak asla tahminde bulunmayın. Gerçek planı EXPLAIN (ANALYZE, BUFFERS) ile alın.

ANALYZE gerçek süreleri ve satır sayılarını verir; BUFFERS önbelleğe mi eriştiğinizi, yoksa diskten mi okuduğunuzu gösterir. Birlikte, sorgunun işlemciye mi, G/Ç'ye mi bağlı olduğunu veya yalnızca gereğinden fazla iş yapıp yapmadığını gösterirler.

Birkaç kez çalıştırın; ilk çalıştırma, süre ölçümünü bozan soğuk önbellek maliyetine maruz kalabilir.

Rastgele arama yaparak planı baştan sona okumayın. Gerçekte en çok zamanın harcandığı düğümü bulun.

Her düğümün kendi süresini hesaplayın: toplam actual time değerinden alt düğümlerin sürelerini çıkarın ve sonucu loops ile çarpın. Payı en büyük olan düğüm hedefinizdir; geri kalan her şey gürültüdür.

Mülakatta şöyle söyleyin: Çalışma süresinin yüzde 80'i bu tek Seq Scan içinde geçiyor; bu nedenle odağımı buraya veriyorum. Başka bir şeyi iyileştirmek boşa çaba harcamak olur.

Baskın düğümde tahmini satır sayısını gerçek satır sayısıyla karşılaştırın. Aradaki büyük fark, planlayıcının ne yaptığını göremediği ve muhtemelen kötü bir plan seçtiği anlamına gelir (yanlış birleştirme algoritması, yanlış erişim yöntemi).

Örnekte tahminin gerçeğin 1000 katı altında kaldığı görülür. Herhangi bir şeyi yeniden tasarlamadan önce istatistikleri yenileyin; bu tek komut planı çoğu zaman ücretsiz olarak düzeltir.

ANALYZE sütun istatistiklerini yeniden hesaplar; VACUUM ANALYZE ayrıca ölü demetleri temizler ve görünürlük haritasını günceller.

En sık görülen ve düzeltilebilen hata şudur: WHERE içinde sütunun etrafına bir işlev veya tür dönüşümü sarılır; bu nedenle dizin kullanılamaz ve altyapı sıralı tarama yapar.

Örnekte, DATE() her satıra uygulandığı için tam tarama zorunlu hâle gelir. Bunu, yalın sütun aralığı yüklemi (sargable biçim) olarak yeniden yazın; böylece created_at üzerindeki dizin devreye girer.

WHERE lower(email)=... için de aynı fikir geçerlidir: normalleştirilmiş verileri saklayın, yalın sütunu sorgulayın veya bir ifade dizini oluşturun.

Baskın düğüm, son derece seçici bir süzgece sahip bir Seq Scan ise veya dizinlenmemiş bir iç anahtar üzerinde loops değeri çok yüksek bir İç İçe Döngü ise çözüm genellikle bir dizindir.

Süzgeç uygulanan ya da birleştirilen sütuna bir dizin ekleyin. Örnekte, birleştirmenin sıralı taramalardan dizin taramalarına geçebilmesi için customer_id üzerinde dizin oluşturulur; planlayıcı da çok daha ucuz bir plan seçebilir.

EXPLAIN ANALYZE komutunu yeniden çalıştırarak doğrulayın; dizinin işe yaradığını varsaymayın.

SELECT * her sütunu diskten ve ağ üzerinden taşır; ayrıca dizin tüm sütunları nadiren kapsadığı için yalnızca dizin kullanan taramaları engeller.

Yalnızca ihtiyacınız olan sütunları seçin. Bu, satır genişliğini küçültür, G/Ç'yi azaltır ve kapsayıcı, yalnızca dizin kullanan bir taramayı mümkün kılabilir.

SELECT * kullanan bir mülakat sorusu, bunu fark etmenizi bekler. Sütun listesini kısaltmak, geniş tablolarda genellikle hızlı ve gerçek bir kazanım sağlar.

Bir Sort veya Hash düğümü disk kullanımı bildiriyorsa (Sort Method: external merge Disk: 25000kB veya Batches: > 1), işlem work_mem sınırını aşmış ve diske taşmıştır.

Seçenekler şunlardır: oturum için work_mem değerini artırmak, sıralamaya veya karma işlemine ulaşan satır sayısını azaltmak (daha erken süzmek) ya da sıralı düzeni sağlayan ve böylece sıralama gereksinimini tamamen ortadan kaldıran bir dizin eklemek.

Bu, mülakat yapanların ödüllendirdiği, kıdemli düzeye uygun kesin bir tanıdır.

Rows Removed by Filter: 9500000 ifadesine dikkat edin. Sorgu on milyon satır okumuş ve neredeyse hepsini atmıştır; bu, boşa harcanan çalışmanın klasik örneğidir.

Çözümler: süzgecin erişim sırasında uygulanması (sonrasında değil) için bir dizin eklemek, yüklemi daha seçici hâle getirmek veya sorguda süzme işlemini daha erkene taşıyarak ağaçta yukarı doğru daha az satır akmasını sağlamak.

Temel ilke şudur: mümkün olan en az işi yapın; mümkün olduğunca erken ve ucuza süzün.

Mülakatta bunu sıralarsanız yolunuzu kaybetmezsiniz:

• EXPLAIN (ANALYZE, BUFFERS) ile Ölçün.
• En çok zaman tüketen düğümü Bulun.
• Tahmini ve gerçek satır sayılarını Karşılaştırın; önce güncelliğini yitirmiş istatistikleri düzeltin.
• Sorgulanabilirliği denetleyin; süzülen sütunlardaki işlevleri kaldırın.
• Seçici süzgeçleri ve birleştirme anahtarlarını Dizinleyin.
• Sütunları Azaltın; SELECT * kullanmaktan kaçının.
• Disk taşmalarını ve gereğinden fazla satır getirilmesini İzleyin.
• Planı yeniden çalıştırarak Doğrulayın.

Tam bir örneği adım adım sözlü olarak açıklayın. Plan, 50 milyon satırlı orders tablosunda bir ardışık tarama, customer_id = 42 filtresi ve 50 milyona yakın Rows Removed by Filter gösteriyor; tahmin de gerçek değerle kabaca örtüşüyor.

Tanı: seçici filtre var, dizin yok ve baskın maliyet tarama. Düzeltme: CREATE INDEX ON orders(customer_id). Yeniden çalıştırın: plan bir dizin taramasına dönüşüyor, süre saniyelerden bir milisaniyenin altına iniyor.

Bu ölç-tanıla-düzelt-doğrula döngüsü, yavaş sorgu sorularının tümü için kullanılacak yanıt şablonudur.

Bir sorgu WHERE YEAR(order_date) = 2026 ile filtreleme yapıyor ve planda, order_date üzerinde mevcut bir B-Ağacı dizini olmasına rağmen tam ardışık tarama görünüyor. En iyi ilk düzeltme nedir?

Artık yavaş sorgu soruları için tekrarlanabilir bir yönteminiz var:

• Her zaman EXPLAIN (ANALYZE, BUFFERS) ile ölçüm yapın ve baskın düğüme odaklanın.
• Tahminlerle gerçek değerler birbirinden ayrıştığında önce güncelliğini yitirmiş istatistikleri düzeltin.
• Koşulları dizinle aranabilir hâle getirin, seçici filtreler ve birleştirme anahtarları için dizinler ekleyin ve SELECT * kullanımını azaltın.
• Diske taşmaları ve gereğinden fazla veri çekmeyi ele alın, ardından yeni planı doğrulayın.

Kontrol listesini anlatın, somut bir değişiklik önerin ve bunu kanıtlamak için planı yeniden çalıştırın; kıdemli bir mühendisten beklenen yanıt budur.