Sipariş Ekranın Aylık Bir Kez Neden Ölüyor: E-pin Satış Yazılımında Kimsenin Konuşmadığı Veritabanı Sorgu Optimizasyonu Dosyası

Sistemin ilk altı ayı hep iyidir. 300 sipariş, 40 ürün, üç bayi. Panel şimşek gibi açılır ve "altyapı sağlam" dersin. Sonra sipariş tablosu 80 bine, log tablosu 2 milyona çıkar ve bir sabah sipariş listesi ekranı 22 saniyede açılmaya başlar. Çoğu satıcı bu noktada aynı yanlış teşhisi koyar: "veritabanı büyüdü, temizlemek lazım." Oysa 80 bin satır bir veritabanı için hiç değildir. Sorun satır sayısı değil, o satırlara nasıl bakıldığıdır.

Bir e-pin satış yazılımının veritabanı yükü, sıradan bir e-ticaretten farklı bir şekil çizer. Yazma işlemleri kısa aralıklarla patlak verir (kampanya, toplu bayi alımı), okuma işlemleri ise küçük ama çok sayıdadır. Buna ödeme bildirimleri, teslimat kayıtları ve bakiye hareketleri eklenir; hepsi aynı anda aynı birkaç tabloya dokunur. Bu yazıda büyüyen bir panelin nerede tıkandığını, hangi sorgunun neden pahalı olduğunu ve dijital ürün satış scripti tarafında hangi düzeltmelerin gerçekten işe yaradığını tek tek göstereceğim. Teorik değil; ölçülebilir maddeler halinde.

Sipariş Listesi Ekranı Neden Tam Olarak Aylık Bir Kez Ölür?

Çünkü sorgunun maliyeti satır sayısıyla doğrusal değil, çoğu zaman çarpımsal artar. Index'i olmayan bir tabloda "son 20 siparişi getir" demek, veritabanına "bütün siparişleri oku, tarihe göre sırala, ilk 20'sini ver" demektir. 3.000 satırda bu iş 40 milisaniye sürer, kimse farketmez. 80.000 satırda 4 saniye, ayrıca her eşzamanlı kullanıcı için tekrar 4 saniye. Beş kişi aynı anda ekranı açtığında sunucu boğulur ve sen "trafik arttı" diye yorumlarsın.

Kritik nokta şu: bu çöküş kademeli değil ani gelir. Veritabanının çalışma kümesi belleğe sığdığı sürece her şey hızlıdır; sığmadığı ilk gün diske inmeye başlar ve performans bir gecede on kat düşer. Yani "dün iyiydi bugün öldü" hissi tamamen normaldir ve index eksikliğinin klasik imzasıdır.

Index Yok Demek, Kasiyerin Her Müşteride Deftere Baştan Bakması Demek

Index'i kitabın arkasındaki dizin gibi düşün. Dizin varsa "ödeme bekleyen siparişler" sorusuna doğrudan ilgili sayfaya gidersin; yoksa kitabı baştan sona okursun. E-pin panelinde hangi kolonların dizine ihtiyacı olduğu ise ekranlara bakarak belirlenir, tahminle değil. Sipariş listesi duruma ve tarihe göre filtreliyorsa index bu ikisini birlikte içermeli. İki ayrı tek kolonluk index, tek bir bileşik index'in yerini tutmaz.

Sık yapılan üç hata var. Birincisi her kolona index eklemek: yazma hızını düşürür, kampanya anında sipariş kaydını yavaşlatır. İkincisi kolon sırasını yanlış kurmak: bileşik index'te seçiciliği yüksek kolon önce gelmelidir. Üçüncüsü index'i olan kolonu fonksiyon içine almak; tarihi biçimlendirerek karşılaştırırsan index devre dışı kalır ve tam tarama geri döner. Bu üç kuralı bilen bir epin yazılım kurulumu, aynı donanımda on kat fazla siparişi sorunsuz taşır.

SELECT * Alışkanlığı Sana Ne Kadara Geliyor?

Bir sipariş satırında 30 kolon olabilir: adres notu, ödeme yanıtının tamamı, teslimat metni, iç notlar. Liste ekranında bunların dördünü gösterirsin. Ama sorgu bütün kolonları çektiği için veritabanı her satırı diskten tam okur, ağ üzerinden taşır, PHP tarafında nesneye çevirir. 200 satırlık bir listede bu, gereksiz taşınan birkaç megabayt demektir. Tek başına ölümcül değil; fakat her ekranda tekrarlandığı için toplamda sunucunun yarısını yer.

Daha sinsi etkisi index kullanımını bozmasıdır. Sadece ihtiyacın olan kolonları seçtiğinde veritabanı bazı sorgulara yalnızca index üzerinden yanıt verebilir, tabloya hiç dokunmaz. Buna kapsayıcı index denir ve ölçülen kazanç genelde üç ila beş kat arasındadır. Yani "gereksiz kolon çekmemek" bir titizlik meselesi değil, doğrudan performans kararıdır.

N+1 Sorgu: Tek Sayfada 400 Sorgu Nasıl Oluşur?

Bu tuzak koda bakınca çok masum görünür. 40 siparişi çeken bir sorgu yazarsın, sonra döngü içinde her sipariş için müşteri adını, ürün başlığını ve ödeme yöntemini ayrı ayrı sorarsın. 1 + 40 + 40 + 40 = 121 sorgu. Bayi paneline teslimat detayını da eklersen 400'ü geçer. Her sorgu tek başına 2 milisaniye sürse bile toplam 0,8 saniye ve bu süre eşzamanlı kullanıcı sayısıyla doğrudan çarpılır.

Çözüm tek kelimeyle toplu çekim. Döngüye girmeden önce gerekli tüm kimlikleri topla, tek sorguyla ilgili kayıtları getir, hafızada eşleştir. 121 sorgu 4 sorguya iner. Bu düzeltme genellikle hiçbir index değişikliği gerektirmez ve panelin en hissedilir hızlanmasını sağlar. Bir e-pin scriptini değerlendirirken sorulacak en teknik ama en ayırt edici soru budur: liste ekranları kaç sorgu çalıştırıyor?

Stok Düşürmede Kilit Stratejisi: Çift Satışın Gerçek Sebebi

E-pin işinde en pahalı veritabanı hatası burada yaşanır. Klasik akış şöyledir: stoktan uygun kodu seç, kullanıcıya ata, kullanıldı olarak işaretle. Üç ayrı adım. İki kullanıcı aynı milisaniyede birinci adımı geçerse ikisi de aynı kodu görür ve ikisine de satılır. Trafik düşükken hiç olmaz, kampanya gecesi sürekli olur; bu yüzden aylarca farkedilmez.

Doğru çözüm, seçme ve işaretlemeyi tek atomik işleme indirmektir. Ya güncellemeyi koşullu yaparsın ("durumu boş olan bir satırı bana ata" ve etkilenen satır sayısını kontrol edersin), ya da satır kilidi alarak işlemi kapatırsın. İkisi de çalışır; çalışmayan tek şey iyimserlikle üç adımı ayrı bırakmaktır. Pinova'daki teslimat akışı koşullu güncelleme üzerine kurulu: kod ancak etkilenen satır 1 döndüğünde satılmış sayılır, aksi halde sipariş otomatik yeniden kuyruğa alınır ve müşteri hiçbir zaman ödeyip boş kalmaz.

Rapor Sorguları Canlı Tabloyu Neden Kilitler?

Aylık ciro ekranını açtığın anda sitenin yavaşladığını farkettin mi? Sebep basit: rapor sorgusu 400 bin satırı tarıyor ve o sırada aynı tabloya sipariş yazılmaya çalışıyor. Canlı işlem tablosu üzerinde ağır toplama yapmak, kasanın önünde envanter saymaya benzer. İşlem durmaz ama herkes bekler.

Ayrım şart: işlemsel veri ile analitik veri aynı tablodan okunmamalı. Pratik çözüm özet tablolarıdır. Günlük ciro, bayi bazlı satış, ürün bazlı adet; bunlar gece bir kez hesaplanıp küçük özet tablolara yazılır. Rapor ekranı 400 bin satır yerine 400 satır okur ve anında açılır. Ayrıca üç aydan eski logları ayrı arşiv tablosuna taşımak, yazma performansını da toparlar. İyi kurulmuş bir dijital ürün satış yazılımı bu arşivlemeyi zamanlanmış görev olarak kendi yapar; sen hatırlamak zorunda kalmazsın. Özellikler listesinde raporlama ve arşiv başlıklarına ayrıca bakmanı öneririm.

Veritabanı optimizasyonu, gösterişli olmadığı için en son bakılan ama ciroyu en doğrudan etkileyen iştir; ödeme sayfası üç saniye beklettiğinde kaybettiğin müşteri geri gelmiyor. Yukarıdaki maddelerin hazır kurulu bir panelde nasıl göründüğünü, 500'den fazla ürünle dolu bir listenin ne kadar hızlı açıldığını canlı demo üzerinde kendin ölç; ardından fiyat sayfasındaki paketlerle karşılaştır.