SQL Server 2005/8 Sorgu Optimizasyonu İpuçları


13

Daha iyi SQL Server sorguları yazma konusunda bir takımı eğitmeye çalışıyorum ve insanların performansı artırmak için en iyi ipuçlarının ne olduğunu merak ediyordum.

Örneğin bir zamanlar sayının (*) sayımdan (1) daha kötü performans göstermesi konusunda ısrar eden bir DBA'm vardı (doğru olup olmadığı veya en son sorgu optimize edicilerine karşı hala geçerli olup olmadığı hakkında hiçbir fikrim yok).

Ekibe hangi basit şeyleri denemesini ve her zaman kullanmasını veya kaçınmasını söylemeliyim? İdeal olarak (a) makul bir fark yaratabilecek ve (b) düz ileri, 1-2 satırlık şeyleri arıyorum.

Yanıtlar:


13

Sorgu ayarı 101

Size bazı ipuçları ve ipuçları verebilmeme rağmen, ayarlamayı sorgulamak için sihirli bir gümüş mermi yok. Yapılacak ilk şey, perde arkasında neler olup bittiğini anlamak. Üçüncü Guru'nun Rehber kitabı gibi iyi bir iç kitap edinin.

Kötü performans gösteren sorgular iki temel çeşide sahiptir: çok uzun süren işlem sorguları ve çok uzun süren toplu işleri (veya raporları) öğütme. Yanlış olan bir sorgunun iyi bir işareti, sorgu planında zamanın% 99'unu alan tek bir öğedir.

İşlem sorguları

Çoğu durumda, kötü performans gösteren bir işlem sorgusu birkaç şeyden biridir:

  • Eksik bir dizin. Bunu çok seçici olması gereken bir birleşimdeki büyük tabloların sorgu planı - tablo taramalarında görebilirsiniz (yani birkaç satır döndürün).

  • Sorgu bir dizin kullanamıyor. Where yan tümcesinde OR koşullarınız varsa, sorguda sarg-yetenekli olmayan hesaplanmış bir değere veya başka bir öğeye katılırsa, sorguyu yeniden yazmanız gerekebilir. Kısaca sargs , satırları ortadan kaldırmak için dizinleri kullanabilen sorgu tahminleridir . Mantıksal AND, eşitlik ve eşitsizliğin (>,> =, <, <= ve! =) Hepsi anlaşılabilir. VEYA geleneksel olarak sarkık değildir. Bununla birlikte, duyguyu OR'den NOT (çubuk ve çubuk değil) tipi yapılara ters çevirerek OR'leri genellikle sarg edilebilir tahminlere dönüştürebilirsiniz.

  • Verimsiz tahminler. Örneğin, where iniç içe geçmiş bir alt sorguya başvuruda bulunuyorsanız, alt öğenin where existsbirleştirme olarak veya birleştirme olarak yeniden yazılabilir olup olmadığına bakın . Bu, daha verimli sorgu planlarına neden olabilir ve burada da deneyebileceğiniz diğer standart yeniden yazma işlemleri bulunmaktadır. Yine, Guru'nun rehber kitapları ve konuyla ilgili diğerleri iyi bir başlangıç ​​noktasıdır.

Toplu sorgular

Toplu sorgular daha karmaşıktır ve farklı ayarlama sorunları vardır. Bazı ipuçları:

  • Dizin. Bu, işlem sorgularıyla aynı nedenden dolayı büyük bir fark yaratabilir. Genellikle eksik bir dizinin iyi bir işareti, makineyi çöpe atmayan görünen uzun, öğütme işlemidir (sorgu planının% 99'u).

  • Geçici tablolar. Bir sorguyu geçici tabloları dolduran çeşitli sorgulara bölmek daha iyi olabilir. Daha büyük sorgular iyileştiriciye daha fazla yer açmak için daha fazla alan sağlar, ancak bu eskiden daha az sorun yaratır. select intoBu işlem minimal olarak günlüğe kaydedilirken (çok daha az günlük etkinliği) geçici tabloları hazırlayın, bu da G / Ç yükünü azaltır.

    Tempdb'deki geçici tabloların, iyileştiricinin ara birleştirme sonuçlarını depolamak için kullandığı veri yapısı ile aynı olduğunu unutmayın, bu nedenle bunu yapmak için herhangi bir performans cezası yoktur. Ayrıca geçici tablo üzerinde, statik tablolardaki sorguları iyileştirdikleri nedenlerle onu okuyan sorguların performansını artırabilecek bir dizin (kümelenmiş ve kapsayan dizinler dahil) da oluşturabilirsiniz.

    Sorgudan geriye doğru izlemeyi zorlaştırabileceğinden geçici tabloları aşırıya kaçmayın. Saklı yordamdaki daha küçük tablolar için, tablo değişkenlerinin yardımcı olup olmadığını sınayın. Bunlar bir bellek içi veri yapısıdır, bu nedenle bir performans kazancı olabilirler.

  • Kümelenmiş ve örtücü dizinler. Bunlar, bazı gruplama sütunlarına dayalı olarak diskteki başvuru yerini zorladığı için bir sorgunun performansını artırabilir. Kümelenmiş bir dizin, toplu işin performansında büyük bir fark yaratabilir.

  • Verimsiz tahminler. Bunlar, işlem sorgularında olduğu gibi sgs ve diğer alt optimizasyon isseslerinde sorunlara neden olabilir.

  • Masa taraması arkadaşın. Popüler inanışın aksine, tablo taramaları doğal olarak kötü değildir. Genellikle bir işlem sorgusunda yanlış bir şeyin işaretidir, ancak genellikle büyük bir toplu işlem yapmanın en etkili yoludur. Bir tablodaki satırların yüzde birkaçından fazlasına sahip bir şey yapıyorsanız, tablo taraması genellikle tabloyu örtmenin en etkili yoludur.

  • İç içe döngüler birleşir. İyileştiricinin birleştirmenin her iki tarafında ne yaptığına bir göz atın. Bunlar örneğin verimsiz olabilir (örneğin, iç içe döngülerin her iki tarafındaki iki büyük tabloyu taramak tablo kümelenir. Kümelenmiş dizinler kullanmayı veya order byişlemi birleştirme birleşimine değiştirmeyi veya bir taraf varsa karma birleştirmeyi teşvik etmeyi deneyin bunu yapmak için yeterince küçük.

Kilitleme

Kilitleme performans sorunlarına da neden olabilir. Sisteminiz yük altında kötü performans gösteriyorsa, kilitlerle ilgili profil ve perfmon sayaçlarına bakın ve önemli bir çekişme olup olmadığını kontrol edin. sp_who2sonuç kümesinde bir sorgunun engellenip engellenmediğini ve neyi engellediğini gösteren bir 'BlkBy' sütununa sahiptir. Ayrıca, 'kilitlenme grafiği' olayları (kilitlenme sorguları varsa) ve kilitle ilgili olayları içeren profiller, kilit sorunlarını gidermek için yararlı olabilir.


1
+1, bu performans ayarlama hakkında bazı harika bilgiler (Kalen'in sınıflarında olmaktan zevk aldım. Ne hakkında olduğunu biliyor!). Dinamik görünümler hakkında bilgi ekleyebilirsiniz.
Wayne

3

En iyi ipucu: SQL Server 2008 kullanın ve testleriniz çalışırken Etkinlik Monitörünü çalıştırın. En uzun / en çok G / Ç, vb. Alan sorguları not alın. Sorguyu ve / veya yürütme planını görüntülemek için bu sorguları sağ tıklayın.

Sonraki: İcra planlarını anlamayı öğrenin.

Sonraki: Veritabanı ayarlama sihirbazını kullanın.

Bu adımlar kendi "en iyi ipuçlarınızı" oluşturmanıza yardımcı olacaktır.



1

İlk olarak, endeksleme. Birçok kişi yabancı anahtarların otomatik olarak dizin almadığını fark etmez. Birleşimlerde kullanıldıkları için neredeyse her zaman bir dizinleri olmalıdır.

Tüm imleçleri, bunun yerine set tabanlı kodla değiştirilip değiştirilemeyeceğini görmek için yakından inceleyin. Bunu yaparak saatlerce saniye koştu kodu değişti.

Alt sorgulardan kaçının. Eğer kodunuz varsa bunları türetilmiş tablolarla birleştirin veya birleştirin.

Nerede cümlenizin aciz olduğundan emin olun.

İcra planlarını okumayı öğrenin.

Ofisin performans ayarı hakkında birkaç iyi kitabı olduğundan emin olun.

Tablo değişkenleri bazı durumlarda geçici tablolardan daha iyidir ve geçici tablolar diğerlerinde daha iyi performans gösterir. Bunları kullanmanız gerekiyorsa, her ikisini de deneyin ve bu durumda hangisinin daha iyi çalıştığını görün.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.