Panel yavaşladığında ilk refleks neredeyse herkeste aynıdır: "sunucu yetersiz, paketi yükseltelim." Daha fazla RAM, daha fazla çekirdek, belki VDS. Bir hafta iyi gider, sonra aynı yavaşlık geri döner. Çünkü sorun kapasitede değildi; sisteminde, günde belki yüz kez çalışan tek bir sorgu vardı ve o sorgu her seferinde yüz binlerce satırı tarıyordu. Donanım büyüdükçe o sorgu da büyümeye devam etti.
Bunu tahmin ederek bulamazsın. "Sanırım sipariş listesi ağır" demek bir teşhis değil. MySQL'in tam bu iş için içinde hazır duran bir aracı var: yavaş sorgu günlüğü. Belirlediğin süreden uzun süren her sorguyu, çalışma zamanıyla, taradığı satır sayısıyla ve tam metniyle bir dosyaya yazar. Doğru okuduğunda, e-pin satış scriptini yavaşlatan sorguyu tahminle değil kanıtla bulursun. Bu yazı o dosyayı açmayı, satırların anlamını ve hangi sayının gerçekten önemli olduğunu anlatıyor.
Günlüğü açmak gerçekten sunucuyu yavaşlatır mı?
En yaygın bahane bu. Gerçek şu: eşiği makul tuttuğun sürece yazma maliyeti ihmal edilebilir düzeydedir, çünkü yalnızca eşiği aşan sorgular kaydedilir ve sağlıklı bir sistemde bunlar zaten azdır. Riskli olan tek ayar, eşiği sıfıra çekip her sorguyu yazdırmaktır; bu diski hem doldurur hem yorar. Teşhis için buna ihtiyacın yok.
Ayarları çalışırken değiştirebilirsin, yeniden başlatma gerekmez: günlüğü etkinleştirir, eşiği bir saniyeye çeker, dosya yolunu belirler ve trafiğin yoğun olduğu bir saati beklersin. Yoğun saat önemlidir; gece yarısı boş sistemden alınan kayıt seni yanıltır. Yirmi dört saatlik tek bir pencere, çoğu dijital ürün satış scripti için ihtiyacın olan her şeyi verir. Mümkünse log_queries_not_using_indexes ayarını da kısa süreliğine aç: indeks kullanmayan sorguları süreden bağımsız yakalar, ama gürültülü olduğu için uzun süre açık bırakma.
Dosyadaki o beş satır tam olarak ne anlatıyor?
Her kayıt bir başlık bloğuyla başlar. Query_time sorgunun kaç saniye sürdüğünü, Lock_time kilit beklemesinde geçen süreyi, Rows_sent istemciye dönen satır sayısını, Rows_examined ise bu sonucu üretmek için MySQL'in kaç satıra dokunduğunu söyler. Altında da sorgunun tam metni yer alır.
Deneyimli göz doğrudan Query_time'a değil, Rows_examined ile Rows_sent arasındaki orana bakar. On satır döndürmek için iki yüz bin satır taranmışsa, o sorgu şu an yavaş olmasa bile veri büyüdükçe kesinlikle yavaşlayacaktır. Query_time bugünü, oran ise yarını anlatır. Bir başka ipucu Lock_time: yüksekse sorgu aslında hızlıdır ama başka bir işlem kilidi bırakmadığı için beklemiştir; o zaman çözüm indeks değil, işlem sınırlarını daraltmaktır.
| Alan | Anlamı | Alarm veren değer | Muhtemel sebep |
|---|---|---|---|
| Query_time | Toplam çalışma süresi | 1 saniyenin üzeri | Tam tablo taraması veya ağır sıralama |
| Rows_examined | Taranan satır sayısı | Rows_sent'in 100 katı ve üzeri | Eksik veya yanlış sıralı indeks |
| Rows_sent | Dönen satır sayısı | Binlerce satır | Sayfalama yok, gereksiz veri çekiliyor |
| Lock_time | Kilit bekleme süresi | 0,1 saniye üzeri | Uzun süren işlem bloğu, kilit çekişmesi |
| Çağrı sıklığı | Aynı desenin tekrarı | Dakikada onlarca | Döngü içinde sorgu, önbellek yokluğu |
Neden en uzun süren sorgu senin gerçek problemin değildir?
Günlüğü açıp en tepedeki 9 saniyelik sorguyu görünce insan hemen ona saldırır. Ama o sorgu günde bir kez çalışan yıl sonu raporu olabilir. Toplam yükü hesaplamanın doğru yolu süre çarpı sıklık. Günde bir kez koşan 9 saniyelik rapor 9 saniye harcar; dakikada kırk kez koşan 0,4 saniyelik sipariş listesi ise saatte on altı dakika harcar. Panelini kilitleyen ikincisidir.
Bu yüzden günlüğü satır satır okumak yerine özetle. MySQL ile birlikte gelen özet aracı, günlükteki sorguları benzer desenlere göre gruplar ve toplam süreye göre sıralar. Elinde bir performans şeması varsa aynı özeti canlı olarak da alabilirsin: sindirilmiş sorgu istatistikleri tablosu, her desen için çağrı sayısını ve toplam beklemeyi tutar. Hedefin dosyanın en üstündeki satır değil, listenin en pahalı deseni olmalı.
E-pin panellerinde yavaş sorguların kaynak dağılımı
- Sipariş ve stok listeleme 45%
- Panel özet ve ciro raporları 25%
- Arama ve filtreleme 20%
- Oturum ve günlük yazma 10%
Paylaşımlı barındırmada dosyaya erişemiyorsan ne yapacaksın?
Paylaşımlı bir hesapta MySQL yapılandırma dosyasına ve sunucu günlüğüne çoğu zaman erişemezsin. Üç çıkış yolun var. Birincisi, günlük çıktısını dosya yerine tabloya yönlendirme iznini sağlayıcıdan istemek; kayıtlar bir sistem tablosuna düşer ve onu normal sorguyla okursun. İkincisi performans şeması üzerinden desen bazlı istatistik çekmek; yazma izni gerektirmez.
Üçüncüsü ve en taşınabilir olanı, ölçümü uygulama tarafına almak: her sorgunun öncesinde ve sonrasında zaman alan, eşiği geçenleri kendi dosyana yazan küçük bir sarmalayıcı. Bu yöntem sunucu izni istemez ve bonus olarak sorgunun hangi sayfadan çağrıldığını da kaydeder; ham MySQL günlüğünde bu bilgi yoktur. İyi kurulmuş bir e-pin yazılımı bu ölçümü zaten içinde taşır ve panelde en yavaş çağrıları listeler.
Teşhis penceresini 24-48 saatle sınırla. Açık kalan bir günlük, aylar sonra diskini dolduran sessiz sebebe dönüşür.
Suçluyu buldun, şimdi ne yapacaksın?
Günlük sana sorgunun metnini verir; nedenini sorgu planı verir. Aynı sorguyu başına açıklama komutu ekleyerek çalıştır ve iki sütuna bak: erişim tipi ve kullanılan anahtar. Erişim tipi tam tarama gösteriyorsa ve anahtar boşsa, MySQL uygun bir yol bulamamış demektir. Filtrelediğin ve sıraladığın kolonları doğru sırada içeren bir bileşik indeks çoğu vakayı tek hamlede çözer.
Bazı vakalarda çözüm indeks değildir. Döngü içinde tek tek çalıştırılan sorgular tek bir toplu sorguya dönüştürülmelidir. Panel özetleri her açılışta baştan hesaplanmak yerine gecelik bir özet tabloya yazılmalıdır. Sınırsız sayfalama LIMIT ile kısıtlanmalı, ihtiyaç duyulmayan kolonlar seçilmemelidir. Doğru düzenlenmiş bir e-pin satış yazılımı bu kalıpları baştan uygular; sonradan eklemek her zaman daha pahalıdır.
| Kontrol | Nasıl yapılır | Beklenen sonuç |
|---|---|---|
| Günlüğü etkinleştir | Eşiği 1 saniyeye çek, dosya yolunu belirle | Kayıt akmaya başladı |
| Yoğun saatte topla | En az bir tam iş günü bekle | Gerçek trafik temsil edildi |
| Desen bazlı özet çıkar | Özet aracıyla toplam süreye göre sırala | İlk 5 pahalı desen listelendi |
| Oranı kontrol et | Rows_examined / Rows_sent hesapla | 100 kat üzeri olanlar işaretlendi |
| Sorgu planını incele | Açıklama komutuyla erişim tipine bak | Tam tarama yapan sorgular bulundu |
| Düzeltmeyi uygula ve ölç | İndeks veya sorgu yeniden yazımı | Aynı desen günlükten kayboldu |
| Günlüğü kapat | Teşhis penceresi bitince | Disk ve yazma yükü normale döndü |
Yavaş sorguyu aramak zorunda kalmadığın bir panel
Pinova, e-pin ve dijital ürün satışını yöneten lisanslı bir yazılımdır; sipariş, stok ve rapor sorguları büyüyen veri hacmi düşünülerek kurgulanmıştır.
Yavaş sorgu eşiğini kaça ayarlamalıyım?
Başlangıç için 1 saniye idealdir. Listeyi temizledikten sonra eşiği 0,3 saniyeye indirip ikinci tur yapabilirsin. Sıfıra çekmek yalnızca kısa bir ölçüm penceresinde, kontrollü şekilde yapılır.
Günlük dosyası çok büyüdü, silebilir miyim?
Dosyayı doğrudan silmek yerine döndürme kullan: yeni bir dosyaya geç, eskisini arşivle. Doğrudan silinen dosyaya MySQL yazmaya devam edebilir ve kayıtlar boşa gider.
Query_time düşük ama Lock_time yüksek, bu ne demek?
Sorgunun kendisi hızlı, ama başka bir işlem tablodaki kilidi bırakmadığı için beklemiş. Çözüm indeks eklemek değil, uzun süren işlem bloklarını kısaltmak ve yazma işlemlerini gruplamaktır.
Performans şeması yavaş sorgu günlüğünün yerini tutar mı?Büyük ölçüde evet: desen bazlı toplam süre ve çağrı sayısını canlı verir, dosya büyütmez. Ancak tek tek kayıtların tam metnini ve zaman damgasını incelemek istediğinde klasik günlük hâlâ daha nettir.
Yavaş sorgu günlüğü, sunucu faturanı büyütmeden önce bakılması gereken ilk yerdir; çünkü çoğu zaman sana "donanım değil, tek bir sorgu" cevabını verir. Kendi kurulumunda bu tür ölçümlerin panelden ne kadar kolay görülebildiğini merak ediyorsan özellikler bölümüne bak, paketleri karşılaştır ve canlı demo üzerinden sipariş listesiyle rapor ekranlarının binlerce kayıtla nasıl davrandığını kendin dene.