Veritabanın Aslında Yavaş Değil, Sana Yanlış Soruyor: E-Pin Scriptinde Gizlenen Sorgu Tıkanıklığını 20 Dakikada Teşhis Etme Yöntemi

Site yavaşladığında ilk refleks neredeyse hep aynıdır: hosting paketini büyütmek. Oysa e-pin ve dijital ürün satan sitelerde yavaşlığın büyük kısmı kaynak darlığından değil, tek bir kötü sorgudan gelir. Çoğu satıcı bunu bilmez, çünkü panelde gördüğü tek şey "sayfa yavaş açılıyor" şikâyetidir. Sunucu grafiklerine bakar, CPU'yu düşük görür, "demek ki sunucu yetiyor" der ve sorunu tema ya da eklenti sanır.

Gerçeği şöyle özetleyebiliriz: veritabanı yavaş değildir, ona yanlış soru soruluyordur. Aynı tabloya saniyede otuz kez sorulan, indeks kullanmayan ve yüz binlerce satırı tarayan bir sorgu, en pahalı sunucuyu bile dize getirir. Bu yazıda bir e-pin satış scripti üzerinde yavaşlığı tahminle değil ölçümle bulmayı, EXPLAIN çıktısında hangi üç satırın gerçekten önemli olduğunu ve indeks eklemenin ne zaman fayda yerine zarar verdiğini anlatıyoruz. Yöntemi uygulamak için veritabanı yöneticisi olman gerekmiyor; sırayı bilmek yeterli.

Yavaşlığın kaynağı çoğu zaman sunucu değil, tek bir sorgu

Dijital ürün satışında veri hacmi küçük başlar, sonra sessizce büyür. Ürün tablosu binlerce satırda kalırken; sipariş, stok hareketi, bakiye işlemi, oturum kaydı ve API log tabloları milyonlara koşar. Ana sayfada "son satılanlar" ya da "stok durumu" gibi masum görünen bir bileşen, bu büyük tabloyu her ziyarette baştan sona taramaya başlar. İlk altı ay hiç fark edilmez, yedinci ayda site aniden ağırlaşır. Değişen kod değil, satır sayısıdır.

Bu yüzden teşhise "hangi sayfa yavaş" diye değil, "hangi sorgu ne kadar toplam süre harcıyor" diye başlamak gerekir. Tek çalışması 40 milisaniye süren ama sayfada 60 kez çağrılan bir sorgu, 900 milisaniye süren tek seferlik bir sorgudan çok daha zararlıdır. Sağlıklı bir dijital ürün satış yazılımı bu tekrarları görünür kılar; görünmüyorsa ilk işin ölçüm katmanını açmak olmalı.

Teşhisin ilk adımı: slow query log'u doğru okumak

Yavaş sorgu günlüğünü açarken en sık yapılan hata eşiği çok yükseğe koymaktır. Eşiği iki saniyeye ayarlarsan, gerçekte sistemi tıkayan yüz milisaniyelik tekrarlı sorguları hiç görmezsin. Teşhis dönemi için eşiği 200 milisaniyeye indir, indeks kullanmayan sorguları da ayrıca kaydet ve günlüğü yalnızca gerçek trafiğin olduğu bir saat boyunca aç. Sonra kapat; sürekli açık kalan ayrıntılı günlük kendi başına yük üretir.

Günlüğü elle okumak yerine özetle. Sorguları normalleştirip toplam süreye göre sıralayan bir araç, sana ilk beş suçluyu on saniyede verir. Burada aradığın liste kısa olur: genellikle bir sipariş listeleme sorgusu, bir stok sayımı, bir kullanıcı bakiye toplamı ve bir rapor ekranı. Bu dördünü düzeltmek, çoğu epin yazılım kurulumunda algılanan yavaşlığın büyük bölümünü bitirir.

EXPLAIN çıktısında hangi üç satırı okursun?

EXPLAIN korkutucu görünür ama pratikte sadece üç şeye bakman yeter. Birincisi erişim tipi: burada "ALL" görüyorsan sorgu tabloyu baştan sona tarıyor demektir, bu neredeyse her zaman düzeltilebilir bir hatadır. İkincisi tahmini satır sayısı: sonuçta 20 satır dönerken tahmin 400.000 ise yanlış indeksle çalışıyorsun. Üçüncüsü ek açıklama alanı: "Using temporary" ve "Using filesort" ifadeleri, sıralama işinin bellekte geçici tablo kurarak yapıldığını, yani indeksin sıralamayı karşılamadığını söyler.

Düzeltme genelde indeksin sırasını değiştirmekle olur. Filtre sütunları önce, sıralama sütunu sonra gelir. Örneğin siparişleri duruma göre filtreleyip tarihe göre sıralıyorsan, indeksi bu iki sütunu bu sırayla kapsayacak biçimde kurarsın. Tek sütunlu iki ayrı indeks aynı işi yapmaz; veritabanı ikisinden yalnızca birini seçer ve diğer işi elle yapar. Bu ayrım, bir e-pin scripti yönetim panelinde sayfa açılışını saniyelerden milisaniyelere indiren en ucuz müdahaledir.

Kilitler: satır kilidi ve sipariş anındaki sessiz kuyruk

Sorgular tek tek hızlı olduğu hâlde site yoğun anda donuyorsa, suçlu neredeyse kesin olarak kilitlerdir. Kilit sorununun imzası nettir: ortalama süre normal, ama bazı isteklerin süresi tam olarak zaman aşımı değerine eşit çıkar. Sebep genellikle işlem kapsamının gereğinden geniş tutulmasıdır. Stok düşümüyle başlayan bir işlemin içine e-posta gönderimi, dış API çağrısı veya log yazımı koyarsan, o satır dış servisin yanıt süresi kadar kilitli kalır.

Kural basittir: işlemin içine yalnızca veritabanı işi girer. Dış dünyaya dokunan her şey işlem bittikten sonra, tercihen kuyruk üzerinden yapılır. İkinci kural, satırlara her zaman aynı sırayla dokunmaktır; farklı sırayla kilitleyen iki akış karşılıklı bekleme üretir ve ölümcül kilit oluşur. Üçüncü kural, uzun raporları canlı tablodan değil okuma kopyasından veya önceden hesaplanmış özet tablosundan çalıştırmaktır.

İndeks eklemek ne zaman zarar verir?

İndeks bedava değildir. Her indeks, her ekleme ve güncellemede ayrıca yazılır. E-pin satışında yazma yoğunluğu yüksektir: her sipariş stok hareketi, bakiye kaydı ve log satırı üretir. Bu tablolara ihtiyatsızca beş altı indeks eklersen okuma hızlanır ama sipariş kaydı yavaşlar. Kampanya anında yazma yavaşlığı, okuma yavaşlığından çok daha pahalıdır.

Doğru yaklaşım, indeksleri de ölçümle yönetmektir. Veritabanının indeks kullanım istatistiklerine bak; aylardır hiç kullanılmayan indeksleri sil. Aynı sütun setini kapsayan iç içe indeksleri teke indir. Çok geniş metin sütunlarını indekslemek yerine arama için ayrı bir alan kullan. Bir e-pin satış yazılımı değerlendirirken şema tarafında bu disiplinin uygulanıp uygulanmadığını sorman, uzun vadeli performansı doğrudan belirler; özellik listesinde veri katmanının nasıl kurulduğuna bakmak iyi bir başlangıç olur.

Şema borcu: log tabloları, arşivleme ve bakım penceresi

Teşhis ettiğin yavaşlığın bir kısmı aslında birikmiş şema borcudur. API çağrı logları, oturum kayıtları, başarısız ödeme denemeleri ve bildirim kuyruğu artıkları hiç temizlenmediğinde bu tablolar ana tablolardan daha büyük hâle gelir. Yedekleme süresi uzar, disk dolar, tablo bakımı imkânsızlaşır. Çözüm karmaşık değil: her log tablosuna bir saklama süresi tanımla ve eski kayıtları aylık parçalar hâlinde arşive taşı.

Arşivlemeyi tek seferde dev bir silme komutuyla yapmak yeni bir kesinti üretir; kayıtları küçük gruplar hâlinde, düşük trafik saatinde ve aralarda soluklanarak taşı. Ayrıca düzenli bir bakım penceresi tanımla: indeks istatistiklerinin yenilenmesi, tablo yeniden düzenlemesi ve yedek geri yükleme denemesi bu pencereye girer. Yedeğini hiç geri yüklemediysen, yedeğin olduğunu değil, olduğunu umduğunu bilirsin.

Veritabanı performansı bir kerelik iş değil, küçük ve düzenli bir alışkanlıktır: ölç, en pahalı beş sorguyu düzelt, indeksi ve arşivi temiz tut. Bu alışkanlığın panelin içine gömülü geldiği bir kurulumu görmek istersen canlı demo üzerinden sipariş ve rapor ekranlarını gerçek veriyle dene, ardından fiyat bölümünden sana uygun paketi seç.