Veritabanı ve Sorgu Performans Optimizasyonu

Yavaş ekranın nedeni her zaman veritabanı değildir

Bir rapor veya liste geç açıldığında sorun ağ, uygulama kodu, harici API, disk, kilit veya veritabanı sorgusu olabilir. Önce uçtan uca süre ölçülür; veritabanının toplam gecikmedeki payı ayrıştırılır. Sorgu optimizasyonu, kanıt olmadan indeks eklemek veya bütün sonuçları önbelleğe almak değil, gerçek darboğazı veri erişim deseniyle birlikte düzeltmektir.

Çalışma sırasında üretim verisine ve iş yüküne zarar vermemek esastır. Ağır profil, şema değişikliği ve indeks oluşturma kontrollü ortam ve zaman penceresinde yapılır. Kişisel veri içeren sorgu ve loglar erişimle sınırlandırılır; rapora gereksiz satır değerleri kopyalanmaz.

Başlangıç ölçümü olmadan iyileştirme kanıtlanamaz

Yavaş olduğu söylenen ekranın URL’si, kullanıcı rolü, filtreleri, veri hacmi, tekrar sıklığı ve saat aralığı kaydedilir. Ortalama süre tek başına uç değerleri gizleyebilir; dağılım, p95/p99 gibi kuyruk davranışı ve hata oranı ihtiyaca göre incelenir. Soğuk ve sıcak önbellek sonuçları ayrılır.

Veritabanı tarafında yavaş sorgu kaydı, uygulama işlem kimliği, sorgu süresi, dönen/okunan satır, kilit bekleme ve kaynak kullanımı birleştirilir. Yalnızca sorgu metnini görmek, onu hangi kullanıcı görevinin ve kaç kez çalıştırdığını açıklamaz. Web sayfasının diğer katmanları için web performansı optimizasyonu bütün istek zincirini ölçebilir.

Sorgu planı neyi gösterir?

EXPLAIN veya veritabanının eşdeğer plan aracı; tablo erişim sırası, kullanılan indeks, tahmini satır, join yöntemi, sıralama ve geçici yapı gibi ipuçları verir. Tahminler gerçek dağılımla farklı olabilir; güvenli ortamda gerçek yürütme istatistiği gerektiğinde dikkatle alınır. Plan çıktısı tek başına “iyi/kötü” etiketiyle değil, beklenen veri hacmi ve sonuç sayısıyla yorumlanır.

• Filtre seçiciliği ve hangi koşulun satır sayısını azalttığı,
• Join alanlarının veri tipi ve collation uyumu,
• Fonksiyon veya dönüşüm nedeniyle indeksin kullanılamaması,
• ORDER BY/GROUP BY için ek sıralama ve geçici tablo maliyeti,
• Yanlış tahmine yol açan eski istatistik veya dengesiz veri dağılımı,
• Tek sorgu kadar aynı istekte tekrarlanan N+1 deseni incelenir.

İndeks tasarımı okuma ve yazma maliyetini dengeler

Her filtre alanına ayrı indeks eklemek doğru değildir. Bileşik indeksin alan sırası sorgunun eşitlik, aralık, sıralama ve join desenine göre belirlenir. Fazla veya yinelenen indeks disk tüketir; ekleme ve güncelleme işlemlerini yavaşlatır. Düşük seçiciliğe sahip tek alan indeksi beklenen katkıyı vermeyebilir.

Sorgu ve veri erişim desenini düzeltmek

Gereksiz bütün sütunları seçmek, büyük OFFSET ile sayfalama, filtreyi uygulama tarafında yapmak, döngü içinde sorgu çalıştırmak ve rapor için her istekte aynı ağır toplamı hesaplamak sık darboğazlardır. İhtiyaç duyulan alan ve satırlar veritabanında doğru koşulla seçilir. Büyük listelerde anahtar tabanlı sayfalama, kullanım biçimine göre OFFSET’e alternatif olabilir.

ORM kullanımı güvenlik ve geliştirme hızını destekleyebilir; ancak üretilen SQL görünmez bırakılmaz. İlişki ön yükleme veya toplu sorgu ile N+1 azaltılır. Ham SQL’e geçmek tek çözüm değildir; veri modeli, indeks ve istek sayısı birlikte ele alınır. Sonuç doğruluğu için eski ve yeni sorgu aynı test veri setinde karşılaştırılır.

Raporlama ve toplu işlemler operasyon ekranından ayrılabilir

Çok yıllık veriyi gruplayan raporun her sayfa açılışında canlı hesaplanması gerekmez. İş gereksinimine göre özet tablo, materialized görünüm benzeri yapı, zamanlanmış hesap veya ayrı rapor kopyası değerlendirilebilir. Güncellik beklentisi açıkça yazılır; “anlık” ifadesinin gerçekten kaç saniye veya dakika olduğu belirlenir.

Toplu güncelleme ve veri aktarımı küçük partilere bölünerek kilit, transaction log ve geri alma maliyeti yönetilebilir. Her partinin kaldığı yer ve hata kaydı bulunur. Büyük geçişlerde veri taşıma ve sistem geçişi mutabakat ve kesim planıyla birlikte yürütülür.

Önbellek güncellik sözleşmesi gerektirir

Önbellek, pahalı ve tekrar eden sorguyu azaltabilir; fakat hangi olayda geçersiz kılınacağı belirlenmezse eski fiyat, stok veya yetki gösterir. Süre tabanlı, olay tabanlı veya sürüm anahtarlı yöntemler veri türüne göre seçilir. Kullanıcıya özel sonuçlar ortak anahtarda saklanmaz; cache key içinde gerekli kapsam bulunur.

Cache stampede gibi aynı anda çok sayıda yenileme isteği için kilit veya erken yenileme düşünülebilir. Önbellek hit oranı, nesne boyutu ve gerçek gecikme katkısı ölçülür; yalnızca kullanılıyor olması fayda kanıtı değildir.

Kilit, transaction ve eşzamanlılık sorunları

Uzun transaction, kullanıcı etkileşimi beklerken açık bırakılmamalıdır. Tablolara farklı sırayla erişen işlemler deadlock üretebilir; uygulama belirli geçici hataları güvenli biçimde tekrar edebilmelidir. İzolasyon seviyesi, tutarlılık ihtiyacı ve kilit maliyetiyle seçilir. Finansal veya stok işlemlerinde doğruluk uğruna gereken kilit kaldırılmaz; kritik bölüm küçültülür.

Yavaşlık yalnızca okuma sorgusundan değil, arka planda çalışan toplu güncelleme veya yedek görevinden gelebilir. Zaman çizelgesiyle kaynak kullanımı karşılaştırılır. Connection pool sınırı, boşta kalan bağlantılar ve aşırı eşzamanlı istekler veritabanını kuyrukta bırakabilir. Uygulama ve sunucu katmanı birlikte izlenir.

Güvenli uygulama ve regresyon doğrulaması

1. Değişiklik öncesi sorgu sonucu, plan, süre ve kaynak ölçümü kaydedilir.
2. İndeks veya sorgu test ortamında gerçekçi veri hacmiyle uygulanır.
3. Sonuç satırları, toplamlar ve sıralama eski davranışla karşılaştırılır.
4. Yazma performansı, disk ve yakın sorgular üzerindeki yan etki ölçülür.
5. Canlı değişiklik için yedek, zaman penceresi ve geri alma hazırlanır.
6. Üretimde sınırlı yayın sonrası hata, kilit ve gecikme yeniden izlenir.

Veritabanı şema değişikliği uygulama sürümüyle koordineli yapılır. Eski kod geri dönecekse yeni indeks genellikle uyumlu olabilir, fakat kolon ve veri tipi değişiklikleri geri dönüşü zorlaştırabilir. Yayın planı web uygulaması test ve UAT senaryolarıyla bağlanır.

Optimizasyon teslimi sürdürülebilir izleme içermelidir

Teslimde başlangıç ve sonuç ölçümleri, incelenen kritik sorgular, uygulanan indeks/SQL değişiklikleri, test sonuçları, geri alma notları ve kalan darboğazlar bulunur. Belirli veri hacminde elde edilen süre başka sunucu veya yükte garanti olarak sunulmaz. Ölçüm koşulları açıkça yazılır.

Başlangıç görüşmesine yavaş ekran örnekleri, tekrar adımı, kullanıcı rolü, veri hacmi, yoğun zamanlar, uygulama ve veritabanı sürümü, son şema değişiklikleri ve erişim kısıtları getirilmelidir. İyi optimizasyon yalnızca bugünkü sorguyu hızlandırmaz; yeni indeks ve kod eklenirken hangi ölçümün ve kontrolün tekrarlanacağını da ekibe bırakır.