Bu Az Bilinen SQL Desenini Kullanarak Sorgu Süremizin %80'ini Kesiyoruz
İçindekiler
Giriş: Bir Sorgunun Çöküş Hikâyesi
Sorunun Kaynağı: Şişmiş Analitik Sorgular
Battle of Queries: CTE Öncesi vs CTE Sonrası
EXPLAIN ANALYZE: CTE Öncesi vs. CTE Sonrası
CTE Kullanırken Dikkat Edilmesi Gereken 5 Kural
Bonus: DBA’yi Mutlu Etmek İstiyorsan EXPLAIN PLAN’ı Sev
Sonuç ve Çıkarımlar
Giriş: Bir Sorgunun Çöküş Hikâyesi
Yavaşlayan sistemler, sabırsız kullanıcılar
Performans krizinin ilk sinyalleri
Bir sistemi batırmanın bin bir yolu vardır, ama en sessiz ve sinsisi, yavaş yavaş şişen bir SQL sorgusudur. Başta her şey masum görünür: iki tablo join, basit bir filtre, üç-beş hesaplama. “Ne olacak canım, bu sorgu taş gibi çalışıyor” dersin. Aylar geçer… Yeni iş gereksinimleri gelir, tablolar büyür, bir join daha eklenir, “şuraya da küçük bir subquery koyayım” dersin. Sonra bir gün fark edersin ki, o sorgu artık küçük bir script değil, tek başına veri ambarını rehin alan 1.2 MB’lık bir canavar olmuş.
Genç mühendisler genelde bu noktada “Aman abi, SQL’e dokunmayalım, çalışıyor işte” der. Çünkü onlar için SQL, eski sistemlerde uyuyan ejderha gibidir: Uyandırırsan sistem çöker, müşteri arar, patron sinirlenir. O yüzden dokunmamak güvenlidir(!).
Ama gerçek şu: Dokunmadığın her sorgu, kendi kendini optimize eden mucizevi bir varlık değil; aksine, bir gün patlamak üzere bekleyen log dolusu bir saatli bomba. Hele bir de sorgu, kritik dashboard’larda veya müşteri-facing API’lerde kullanılıyorsa… O patlama, sadece veri tabanını değil, sana olan güveni de yerle bir eder.
Bizim hikâyemiz tam da böyle başladı. Sistem yük altındaydı. Dashboard’lar time-out veriyordu. Müşteri destek ekibi “Bir problem mi var?” diye sormaktan “Yine mi sorgu patladı?” moduna geçmişti. Loglarda kırmızı satırlar, monitoring ekranında CPU grafikleri Himalaya Dağları gibi… Ve bütün bu kaosun merkezinde tek bir SQL sorgusu vardı.
Kötü haber: Bu sorgu, o kadar çok serviste, o kadar çok yerde kullanılıyordu ki, doğrudan optimize etmeye kalkmak camdan yapılmış uçan bir uçağın motorunu havada değiştirmeye benziyordu. İyi haber: Bir mühendis, kimsenin aklına gelmeyen bir CTE hilesiyle durumu kurtardı.
Sorunun Kaynağı: Şişmiş Analitik Sorgular
Veritabanı performans sorunlarının %80’i, aynı 3 sebepten çıkar:
İhtiyacından fazla veri çekmek (SELECT * sendromu)
Gereksiz join ve filtreler (Birleştireyim de dursun mantığı)
Aynı hesaplamayı defalarca yapmak (Copy-paste mühendisi yaklaşımı)
Bizim sorgu bu üç günahın hepsini işlemişti. Basit bir rapor olarak başlamış, zamanla “acil bir şey ekleyelim” talepleriyle Frankenstein’a dönmüştü.
Biraz gözünüzde canlansın diye (ve DBA’ların tüylerini diken diken etmek için) şuraya basitleştirilmiş versiyonunu bırakıyorum:
Yorumlar
Yorum Gönder