Dinamik bir sitede performans sorunlarının büyük bölümü veritabanı katmanından gelir. Sunucu yükseltmek bu sorunları bir süre örter ama çözmez — çünkü sorunun kaynağı kapasite değil, indekslenmemiş bir sorgu ya da varsayılan ayarlarla bırakılmış bir veritabanı sunucusudur.
Bu rehber, kendi sanal sunucunuz üzerinde veritabanı performansını ölçmeyi ve iyileştirmeyi anlatıyor.
Varsayılan Ayarlar Sizin İçin Değil
Paket yöneticisinden kurulan bir veritabanı sunucusu, çok küçük makinelerde de çalışabilecek muhafazakâr varsayılanlarla gelir. 8 GB belleği olan bir sunucuda, veritabanı belki birkaç yüz megabaytlık bir bellek havuzuyla çalışıyordur.
Sonuç şudur: belleğe sığabilecek veri diskten okunur. Disk, bellekten kat kat yavaştır ve bu fark her sorguda çarpan etkisi yapar. Kurulumdan sonra bellek havuzunu sunucunun gerçek kapasitesine göre ayarlamak, veritabanı optimizasyonunda en yüksek getirili tek adımdır.
Pratik hedef: aktif veri kümenizin belleğe sığması. Veritabanınızın toplam boyutu belleğe sığıyorsa, sorgular pratikte hiç diske gitmez.
Ölçüm: Nereden Başlamalı?
Optimizasyona tahminle başlamayın. Üç ölçüm, sorunun yerini genellikle ilk turda gösterir.
1. Yavaş Sorgu Kaydı
Belirli bir süreden uzun süren sorguları kaydeden mekanizmayı açın ve birkaç saat çalıştırın. Karşınıza çıkan tablo neredeyse her zaman aynıdır: yüzlerce sorgunun içinde iki üç tanesi toplam sürenin büyük bölümünü tüketir.
Buradaki kazanç oransızdır — üç sorguyu düzeltmek, tüm sistemi hızlandırır.
2. Sayfa Başına Sorgu Sayısı
Tek bir sayfa yüklemesi kaç sorgu üretiyor? Onlarca sorgu normal olabilir; yüzlercesi bir sorun işaretidir.
Yüzlerce sorgunun tipik nedeni N+1 problemidir: bir liste çekilir, sonra listedeki her kayıt için ayrı bir sorgu daha atılır. 100 ürünlük bir sayfa 101 sorgu üretir. Çözüm, veriyi tek bir sorguda birleştirerek çekmektir ve etkisi anında hissedilir.
3. İndeks Kullanımı
Yavaş sorguların çoğunun nedeni eksik indekstir. İndeksi olmayan bir sorgu, tabloyu baştan sona tarar; tablo büyüdükçe süre doğrusal olarak artar. İndeksli aynı sorgu, tablo boyutundan neredeyse bağımsız çalışır.
Bu yüzden "site büyüdükçe yavaşlıyor" şikayetinin arkasında genellikle indeks eksikliği vardır.
İndeksleme: Doğru Ölçü
İndeks bedava değildir: okumayı hızlandırır, yazmayı yavaşlatır ve disk alanı tüketir. Her sütuna indeks eklemek çözüm değil, yeni bir sorundur.
| İndekslenmeli | İndekslenmemeli |
|---|---|
| Filtreleme koşullarında geçen sütunlar | Yalnızca birkaç farklı değer alan sütunlar |
| Tablo birleştirmelerinde kullanılan sütunlar | Sorgularda hiç kullanılmayan sütunlar |
| Sıralama yapılan sütunlar | Çok sık güncellenen, nadiren sorgulanan sütunlar |
| Yabancı anahtarlar | Çok uzun metin sütunları (tam metin indeksi ayrı konu) |
Birden fazla sütunla filtreleme yapıyorsanız, ayrı ayrı indeksler yerine bileşik indeks kullanın. Bileşik indekste sütun sırası önemlidir: en seçici sütun başta olmalıdır.
Düzenli Bakım
- Tablo istatistiklerini güncel tutun. Sorgu planlayıcısı, hangi yolu seçeceğine istatistiklere bakarak karar verir. Bayat istatistikler, doğru indeks olsa bile yanlış plan seçilmesine yol açar.
- Kullanılmayan indeksleri kaldırın. Zamanla eklenip unutulan indeksler yazma performansını sessizce düşürür.
- Şişmiş tabloları toparlayın. Yoğun silme/güncelleme yapılan tablolarda disk üzerinde boşluk birikir.
- Eski veriyi arşivleyin. Üç yıllık log kaydını aynı tabloda tutmak, her sorguyu yavaşlatır. Arşiv tablosuna taşımak basit ve etkilidir.
Bağlantı Yönetimi
Veritabanı bağlantısı kurmak pahalı bir işlemdir. İki uçtan da hata yapılır: her istekte yeni bağlantı açmak gereksiz maliyet üretir; bağlantı sayısını sınırsız bırakmak ise bellek tükenmesine yol açar.
Eşzamanlı bağlantı sınırını, web sunucunuzun aynı anda çalıştırabileceği işçi sayısıyla uyumlu belirleyin. Sınır çok düşükse istekler bağlantı bekler; çok yüksekse her bağlantının tükettiği bellek toplamda sunucuyu zorlar.
Yedekleme: Tutarlılık Meselesi
Veritabanı yedeklemesinde en sinsi hata, tutarsız döküm almaktır. Yazma trafiği devam ederken alınan basit bir döküm, tabloları farklı anlardan yakalayabilir — dosya geri yüklendiğinde ilişkiler tutmaz ve bunu ancak kurtarma anında fark edersiniz.
Dökümü tutarlı bir anda alacak şekilde yapılandırın ve alınan yedeği düzenli olarak gerçekten geri yükleyerek test edin. Bir veritabanı yedeği, geri yüklendiği kanıtlanana kadar bir varsayımdır.
Sonuç
Veritabanı performansında sıra nettir: önce bellek havuzunu doğru ayarla, sonra yavaş sorguları bul, sonra eksik indeksleri ekle. Bu üç adım, çoğu sitede donanım yükseltmesinden daha büyük kazanç sağlar ve hiçbir ek maliyeti yoktur. Kaynakların size ayrıldığı bir VDS ortamında bu ayarların tamamı sizin kontrolünüzdedir — paylaşımlı barındırmada çoğuna erişemezsiniz. Kaynak eklemeyi son adım olarak saklayın.
Sıkça Sorulan Sorular (SSS)
Veritabanına ne kadar bellek ayırmalıyım?
Sunucu yalnızca veritabanı çalıştırıyorsa toplam belleğin büyük bölümü ayrılabilir. Aynı sunucuda web sunucusu da varsa, ona ve işletim sistemine yeterli pay bırakmalısınız. Ölçüt şudur: takas alanı hiç kullanılmamalı. Kullanılmaya başlıyorsa fazla ayırmışsınız demektir.
Kaç indeks fazla sayılır?
Sabit bir sayı yoktur; ölçüt kullanımdır. Hiç kullanılmayan her indeks yazma performansını düşürür ve disk tüketir. Düzenli olarak indeks kullanım istatistiklerine bakıp kullanılmayanları kaldırın.
Yavaş sorgu kaydı performansı etkiler mi?
Eşiği makul bir değerde tutarsanız etkisi ihmal edilebilir. Eşiği çok düşük ayarlamak (örneğin her sorguyu kaydetmek) ise ciddi disk yazımı üretir. Teşhis için birkaç saat açık tutup sonra kapatmak en pratik yaklaşımdır.
Veritabanını ayrı bir sunucuya taşımalı mıyım?
Tek sunucu kaynakları yetiyorsa gerekmez — ayırmak ağ gecikmesi ekler. Ayırma kararı, kaynak rekabeti gerçekten sorun olduğunda veya yüksek erişilebilirlik için veritabanı çoğaltması kuracağınızda anlamlıdır.
