- Konu sahibi
- #1
SQL için doğru planlama, önce uygulamanın hangi verileri saklayacağını ve hangi sorulara yanıt vereceğini belirlemekle başlar. Ardından tabloları ve ilişkileri tasarlar, veri bütünlüğü kurallarını tanımlarsınız. Sık kullanılan sorguları temsilî verilerle ölçerek dizinleri ve sorguları iyileştirirsiniz. Sonuç, yalnızca çalışan bir sorgu değil; doğru veriyi üreten ve beklenen iş yükünde sınanmış bir veritabanı tasarımıdır.
Her kayıt için benzersiz bir birincil anahtar, ilişkili kayıt için de yabancı anahtar planlayın. Zorunlu alanları, uygun veri türlerini ve gerekli benzersizlik kurallarını belirleyin. Örneğin bir siparişin müşterisiz kaydedilmemesi gerekiyorsa, müşteri kimliğini hem zorunlu alan hem de müşteriler tablosuna başvuran yabancı anahtar olarak tanımlayın. Bu kurallar, uygulama kodu dışında yapılan hatalı girişlere karşı da veritabanında koruma sağlar.
Sık çalışacak işlemleri de yazın: Bir müşterinin son siparişleri listelenecek mi, tarih aralığına göre rapor alınacak mı, aynı anda kaç kayıt güncellenecek? Bu cevaplar tablo ve dizin kararlarını yönlendirir. Veri hacmini ve yoğun dönemleri kesin rakamlarla bilmiyorsanız tahminlerinizi varsayım olarak kaydedin; test verilerini oluştururken bu varsayımları kullanın.
Müşteri 42'nin belirtilen aralıkta iki siparişi varsa sonuç iki satırdır; hiç siparişi yoksa sonuç boş gelir. Boş sonuç tek başına sorgunun hatalı olduğunu kanıtlamaz: Müşteri kimliğini ve kayıtların tarihlerini kontrol edin. Tarih alanı zaman da içeriyorsa yıl sonunu kapsamak için sonraki yılın başlangıcını dışlayan aralık kullanmak, günün son saatini ayrıca hesaplamayı gerektirmez.
Sorgunun doğru sonuç vermesi, yeterince hızlı olduğunu göstermez. Özellikle büyük tabloda aynı sorgunun ne sıklıkla çalıştığını ve ne kadar veri okuduğunu ölçmek gerekir.
Örneğin PostgreSQL'de, üretim verisini temsil eden bir test ortamında aşağıdaki komut dizini oluşturur. Tablo ve dizin oluşturma yetkiniz olmalıdır:
Dizini eklemeden önce ve ekledikten sonra aynı sorgunun yürütme planını karşılaştırın. PostgreSQL'de sorgunun başına
Planın dizin taraması göstermesi tek başına daha iyi performansın kanıtı değildir; az sayıda kayıt içeren veya tablonun büyük bölümünü döndüren bir sorguda tablo taraması daha uygun olabilir. Benzer veri hacmi ve koşullarda süreyi ve okunan veriyi karşılaştırın. Tahmin edilen satır sayısı gerçekle çok farklıysa istatistiklerin güncelliğini inceleyin; gerekiyorsa PostgreSQL'de ilgili tablo için
Canlı ortama geçmeden önce değişiklikleri sürümlü bir SQL dosyasında saklayın; yedekleme, geri dönüş ve bakım planını hazırlayın. Dizin oluşturmanın canlı sistemde yaratabileceği yük ve kilitlenmeyi kullandığınız sistem ve sürüm için değerlendirin. Uygulamadan sonra aynı sorgu ve iş yükü ölçümlerini izleyin; beklenmedik yavaşlamada değişikliği gözden geçirip hazırladığınız geri dönüş yolunu kullanın.
Veriyi ve yapılacak işlemleri belirleyin
Önce uygulamanın ihtiyaçlarını somutlaştırın: Hangi kayıtlar tutulacak, kimler ekleme veya değişiklik yapacak, hangi listeler ve raporlar alınacak? Örneğin bir mağazada müşteriler ve siparişler ayrı varlıklardır; müşteri bilgilerini her sipariş satırına tekrar yazmak yerine siparişi müşteriye bağlamak, güncelleme sırasında tutarsızlık riskini azaltır.Her kayıt için benzersiz bir birincil anahtar, ilişkili kayıt için de yabancı anahtar planlayın. Zorunlu alanları, uygun veri türlerini ve gerekli benzersizlik kurallarını belirleyin. Örneğin bir siparişin müşterisiz kaydedilmemesi gerekiyorsa, müşteri kimliğini hem zorunlu alan hem de müşteriler tablosuna başvuran yabancı anahtar olarak tanımlayın. Bu kurallar, uygulama kodu dışında yapılan hatalı girişlere karşı da veritabanında koruma sağlar.
Sık çalışacak işlemleri de yazın: Bir müşterinin son siparişleri listelenecek mi, tarih aralığına göre rapor alınacak mı, aynı anda kaç kayıt güncellenecek? Bu cevaplar tablo ve dizin kararlarını yönlendirir. Veri hacmini ve yoğun dönemleri kesin rakamlarla bilmiyorsanız tahminlerinizi varsayım olarak kaydedin; test verilerini oluştururken bu varsayımları kullanın.
Örnek sorguyla tasarımı sınayın
Varsayımsal bir mağazadasiparisler tablosunda id, musteri_id ve siparis_tarihi alanları bulunduğunu düşünün. İhtiyaç, belirli bir müşterinin 2026 yılındaki siparişlerini yeniden eskiye sıralamaktır. Aşağıdaki sorguyu kendi veritabanı aracınızda çalıştırmadan önce tablo ve alan adlarını mevcut şemanızla eşleştirin:
SQL:
SELECT id, siparis_tarihi
FROM siparisler
WHERE musteri_id = 42
AND siparis_tarihi >= '2026-01-01'
AND siparis_tarihi < '2027-01-01'
ORDER BY siparis_tarihi DESC;Müşteri 42'nin belirtilen aralıkta iki siparişi varsa sonuç iki satırdır; hiç siparişi yoksa sonuç boş gelir. Boş sonuç tek başına sorgunun hatalı olduğunu kanıtlamaz: Müşteri kimliğini ve kayıtların tarihlerini kontrol edin. Tarih alanı zaman da içeriyorsa yıl sonunu kapsamak için sonraki yılın başlangıcını dışlayan aralık kullanmak, günün son saatini ayrıca hesaplamayı gerektirmez.
Sorgunun doğru sonuç vermesi, yeterince hızlı olduğunu göstermez. Özellikle büyük tabloda aynı sorgunun ne sıklıkla çalıştığını ve ne kadar veri okuduğunu ölçmek gerekir.
Dizin ve yürütme planını ölçerek seçin
Dizin, belirli sütunlardaki kayıtlara erişimi kolaylaştıran ek bir veri yapısıdır. Yukarıdaki sorguda müşteri ve tarih birlikte kullanıldığı için(musteri_id, siparis_tarihi) üzerinde birleşik bir dizin denenebilir. Ancak her dizin ek depolama ve yazma maliyeti getirir; her sütuna otomatik olarak dizin açmak yerine gerçek sorgulara göre karar verin.Örneğin PostgreSQL'de, üretim verisini temsil eden bir test ortamında aşağıdaki komut dizini oluşturur. Tablo ve dizin oluşturma yetkiniz olmalıdır:
SQL:
CREATE INDEX siparisler_musteri_tarih_idx
ON siparisler (musteri_id, siparis_tarihi);Dizini eklemeden önce ve ekledikten sonra aynı sorgunun yürütme planını karşılaştırın. PostgreSQL'de sorgunun başına
EXPLAIN (ANALYZE, BUFFERS) ekleyerek tahmin edilen ve gerçekleşen satır sayılarını, çalışma süresini ve tampon kullanımını görebilirsiniz. ANALYZE sorguyu gerçekten çalıştırır: Özellikle veri değiştiren komutlarda canlı ortamda gelişigüzel kullanmayın.Planın dizin taraması göstermesi tek başına daha iyi performansın kanıtı değildir; az sayıda kayıt içeren veya tablonun büyük bölümünü döndüren bir sorguda tablo taraması daha uygun olabilir. Benzer veri hacmi ve koşullarda süreyi ve okunan veriyi karşılaştırın. Tahmin edilen satır sayısı gerçekle çok farklıysa istatistiklerin güncelliğini inceleyin; gerekiyorsa PostgreSQL'de ilgili tablo için
ANALYZE siparisler; çalıştırıp planı yeniden ölçün. Plan komutları ve ayrıntıları veritabanı sistemine göre değişir.Değişikliği güvenli biçimde uygulayın
Tasarımı ve sorguları küçük bir örnekle doğruladıktan sonra temsilî hacimde, okuma ve yazma işlemlerini birlikte test edin. Sorgunun döndürdüğü satırların doğruluğunu, işlem süresini ve yeni dizinin yazma işlemlerine etkisini karşılaştırın. İyileşme yoksa dizin sütunlarının sırasını ve sorgunun gerçekten en sık kullanılan koşulları yansıtıp yansıtmadığını gözden geçirin.Canlı ortama geçmeden önce değişiklikleri sürümlü bir SQL dosyasında saklayın; yedekleme, geri dönüş ve bakım planını hazırlayın. Dizin oluşturmanın canlı sistemde yaratabileceği yük ve kilitlenmeyi kullandığınız sistem ve sürüm için değerlendirin. Uygulamadan sonra aynı sorgu ve iş yükü ölçümlerini izleyin; beklenmedik yavaşlamada değişikliği gözden geçirip hazırladığınız geri dönüş yolunu kullanın.
Moderatör tarafında düzenlendi:
