Saklı yordamlar ve ham sorgular arasında etkinlik

Bu tartışmanın her iki tarafında da çok şey okudum: yalnızca ham sorgular üzerinde saklı yordamlar kullanarak elde edilebilecek önemli bir performans kazancı var mı? SQL Server ile özellikle ilgileniyorum ancak tüm veritabanlarıyla ilgileniyorum.

Daha az SQL Server 2008 ve daha yüksek, ancak hala orada. Asıl konu, yürütme planı önbelleği ve SQL Server, gönderilen sorguları otomatik olarak parametreleştirebilmektir. Saklı yordamlar kullanıldığında (içinde dinamik SQL olmayan) sorgular zaten parametreleştirilir; Planlar önceden plan önbelleğinde depolandığı için çalıştırıldığında her sorgu için bir plan oluşturmaya gerek yoktur.

Ayrıca saklı yordamları kullanırken giderilen güvenlik sorunlarını (dinamik SQL, minimum izinler vb.) Unutmayın.

Uygulama, tablolardaki verileri seçmek, eklemek, güncellemek ve silmek için temel tablolara karşı dinamik SQL kullanıyorsa, uygulamanın tüm bu nesnelere doğrudan hak vermesi gereken tablolarda. Dolayısıyla, birisi sunucuya girmek için SQL Injection kullanıyorsa, bu tablolardaki tüm verileri sorgulama, değiştirme veya silme haklarına sahip olacaktır.

Saklı yordamları kullanıyorsanız, yalnızca saklı yordamın döndüreceği bilgileri geri alarak saklı yordamları yürütme haklarına sahip olurlar. Hızlı bir silme ifadesi vermek ve her şeyi mahvetmek yerine, verileri silmek için hangi prosedürlerin kullanılabileceğini bulmaları ve prosedürü nasıl kullanacaklarını bulmaları gerekir.

SQL Injection'ın bir veritabanına girmenin en kolay yolu olduğu göz önüne alındığında, bu oldukça önemlidir.

Denny'nin cevabına bir zeyilname olarak, proc'lar üzerinden yapılan sorgulamalar sonucunda oluşturulan tek veya düşük kullanımlı geçici yürütme planlarında önemli tampon havuz belleğinin boşa harcandığı sistemleri bulmak nadir değildir.

Son zamanlarda en kötü durum, bir örneğe ayrılan 8 GB, 3 GB plan önbelleği, 2,5 GB tek kullanımlık planları. Bunların çoğu SQL2005 olmuştur, bu nedenle geçici iş yükleri için en iyi duruma getirme ayarını denemek için bir seçenek olmamıştır.

Ham sorgular üzerindeki prosedürlerin gerekçelerine performansın dahil edilmesi kesinlikle zorlaşıyor. Şimdi benim için en güçlü argümanlardan biri "Prosedürleri kullanıyorsanız, performans sorunları ortaya çıktığında yardım etmek benim için çok daha kolay" dır. Dinamik / linq / orm arayüzü ayarlama yapmanıza engel olmaz, ancak seçeneklerinizi ciddi şekilde sınırlayabilir.

SQL Server, saklı yordamları ve geçici SQL'i aynı şekilde önbelleğe alır ve optimize eder. Örneğin, bu prosedür:

create procedure dbo.TestSB(@id int) as select * from Orders where id = @id

Aşağıdakiler ile aynı şekilde optimize edilir ve önbelleğe alınır:

select * from Orders where id = @id

Ancak, aşağıdaki geçici SQL, kodlanmış değer nedeniyle etkili bir şekilde önbelleğe alınamaz:

select * from Orders where id = 42

Performans aynı olmasına rağmen, saklı yordamları kullanmak için iyi nedenler vardır. Saklı yordamlar DBA ve uygulama geliştiricileri arasında açık bir ayrım sağlar. Değerli verileriniz ve sürekli değişen programlar arasında ekstra bir savunma katmanı olması iyi bir şey :)