Sorgu Performansı Ayarlama

Bir sorgu / depolanmış proc / işlev yazmayı bitirdiğinizde, bazı performans parametrelerini hızlı bir şekilde almanın en bilgilendirici yolu nedir? Sorguyu çalıştırıyor ve gerçek yürütme planını görüntülüyor musunuz? Eğer öyleyse, aradığınız şeyler nelerdir? Tabii ki tablo / dizin taramaları bit vuruşlarıdır, ama başka ne var?

Hızlı bir değerlendirme için, yürütme planını SSMS'den çıkarın ve Plan Explorer'a girin .

• Beklenmedik şeyler için en pahalı işlemleri gözden geçirin. Sıralar, çalışma masaları, uygunsuz birleştirme işleçleri (örneğin bir birleştirme veya karma beklediğiniz iç içe döngü).
• Planın her bir aşamasındaki satır sayılarına bakın, geniş ölçüde görmeyi beklediğiniz aralıkta mı?
• Tahmini ve gerçek satırlara bakın. Gerçek veriler tahminlere yakınsanız, iyi bir planınız olması muhtemeldir. Büyük varyasyonlar varsa, nedenini öğrenin (örneğin eksik ve / veya güncel olmayan istatistikler).
• Parametre koklama sorunlarının potansiyelini değerlendirin. Kardinalitenin değişebileceği alanları arayın ve bir dizi giriş parametresine karşı test edin.

Çok sayıda ücretsiz referans malzemesi olan Grant Fitchley'nin SQL Server Yürütme Planları iyi bir başlangıç. Ayrıca Joe Chang'ın blog yazılarını ve yürütme planı maliyetleriyle ilgili e-kitabı çok yararlı buldum .

Çoğunlukla, yaptığım tek şey sadece sorguyu çalıştırmak ve gerçek dünya verilerine karşı nasıl yürütüldüğünü öğrenmek. Bir sorun varsa, yürütme planlarına bakarım.

İcra planlarına gelince, Brad McGehee'nin bu konuda ilginç bir makalesi var.

İçinde diyor:

Bir yürütme planında aşağıdakilerden herhangi birini görürseniz, uyarı işaretlerini dikkate almalı ve olası performans sorunları için araştırmalısınız. Her biri performans açısından ideal olandan daha az.

* Index or table scans: May indicate a need for better or additional indexes.

* Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement.

* Filter: Remove any functions in the WHERE clause, don’t include wiews[sic] in your Transact-SQL code, may need additional indexes.

* Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently? 

Bunlardan kaçınmak her zaman mümkün değildir, ancak onlardan ne kadar çok kaçınırsanız, daha hızlı sorgu performansı olacaktır.

SET STATISTICS IO ON

Genel olarak, "mantıksal okuma sayısı" mümkün olduğunca düşük olmalıdır. Sorguyu tamamlamak için birkaç sayfaya dokunduğunuzda, plan daha hızlı olacağından (genellikle) daha iyi, CPU, RAM ve disk G / Ç üzerinde daha az etki olur.

Bu, SQL dizinlerini değiştirirken veya yeniden çarpanlarına ayırırken size yardımcı olacaktır. "Milisaniye hariç tutma süresine" bakmak aynı SQL ve sorgu planıyla bile değişecektir - mantıksal okumalar herhangi bir sorgu planı için tutarlı kalacaktır.

Ayrıca "fiziksel okumalar" çok düşük olmalıdır (ve sonraki yürütmeler için sıfır olmalı ve sıfır olmalıdır) Bunu yapmazsanız, SQL Server bellek kullanımınıza bakın (sayfa ömrü vb.).