Dizin oluşturmak yerine İSTATİSTİK oluşturmak ne zaman daha iyidir?

Neler STATISTICS olduğu hakkında çok fazla bilgi buldum : nasıl tutuldukları, sorgulardan veya dizinlerden manuel veya otomatik olarak nasıl oluşturulabilecekleri vb. Ancak, ne zaman ile ilgili herhangi bir rehberlik veya "en iyi uygulamalar" bilgisi bulamadım .Onları oluşturmak için: Hangi durumlar bir Endekse göre elle oluşturulmuş bir STATISTICS nesnesinden daha fazla yararlanır. Bölümlenmiş tablolardaki sorgulara yardımcı olan filtrelenmiş istatistikler oluşturduğumu gördüm (çünkü dizinler için oluşturulan istatistikler tüm tabloyu kapsar ve bölüm başına değil - brillaint!); Bir endeksin detayına ihtiyaç duymamak, endeksi sürdürmenin veya blokaj / kilitlenme şansını arttırmanın maliyetine değmez.

@JonathanFite, yorumunda, dizinler ve istatistikler arasındaki farktan bahsetti:

Dizinler, SQL'in tablodan farklı şekilde sıralanmış aramalar oluşturarak verileri daha hızlı bulmasına yardımcı olur. İstatistikler, SQL'in sorguyu karşılamak için ne kadar bellek / çaba gerekeceğini belirlemesine yardımcı olur.

Bu harika bir bilgi, çünkü sorumu netleştirmeme yardımcı oluyor:

Bu nasıl bilerek (veya başka herhangi bir teknik bilgi vermez neyi s ve nasıl davranışlar ve doğası ile ilgili s STATISTICS) yardımıyla belirlemek zaman seçim için CREATE STATISTICSüzerinde CREATE INDEXilgili yaratacak bir Index oluştururken özellikle, STATISTICSnesneyi? Dizine sahip olmamak ve sadece İSTATİSTİK bilgisine sahip olmakla hangi senaryo daha iyi sunulacak ?

Mümkünse, STATISTICSnesnenin bir karakterden daha uygun olduğu bir senaryo için çalışan bir örneğe sahip olmak süper yararlı olacaktır INDEX.

Görsel bir öğrenen / düşünür olduğum için , yan yana olan STATISTICSve arasındaki farkları INDEX, yan yana, ne zaman STATISTICSdaha iyi bir seçim yapılacağının belirlenmesine yardımcı olacak bir araç olarak görmenin yardımcı olabileceğini düşündüm .

Thingy           PROs                             CONs
-------          ----------                       -------------------
INDEX            * Can help sorts.                * Takes up space.
                 * Contains data (can             * Needs to be maintained (extra I/O).
                   "cover" a query).              * More chances for blocking / dead-locks.

STATISTICS       * Takes up very little space.    * Cannot help sorts.
                 * Lighter maintenance / won't    * Cannot "cover" queries.
                   slow down DML operations.
                 * Does not increase chances
                   of blocking / dead-locks.

Aşağıdakiler, bu soruyu soran, hatta aynı soruyu soran, fakat cevaplanmayan bazı kaynaklar.

SQL Server Dizini - İstatistik

SQL Server İstatistik Soruları Sormak İçin Çok Utangaç Olduk

İstatistik. Çok noktalı virgül histogramları mümkün mü?

** Açık olmak gerekirse, bunun için bir cevabım yok ve aslında birkaç kişinin interweb'lerde garip bir şekilde eksik olan bilgiyi sağlaması için birkaç kişiden geri bildirim almak istiyorum.

Sorgu etrafında döner - Ne zaman sadece istatistik oluşturmak vs indeks (istatistik oluşturmak) oluşturmak için iyi bir şeydir.

Sql sunucum dahili notlarımdan (SQLSkills sınıfı - IE1 ve IE2) ve SQL Server dahili kitabımdan , benim sınırlı anlayışım:

SQL Server istatistikleri, dizin anahtarı değerleri ve normal sütun değerleri hakkında hayati bilgiler içeren sistem nesnelerinden başka bir şey değildir.

SQL Server, "yeterince iyi" bir yürütme planını mümkün olan en hızlı şekilde seçmek için maliyet tabanlı bir model kullanır. Karibilite tahmini (sorgu uygulamasının her aşamasında işlenecek satır sayısını tahmin etme), başlangıç ​​stratejisini, bellek verme gereksinimini, çalışan iş parçacığı seçimini ve verilere erişirken endeks seçimini etkileyen başlangıçta sorgu optimizasyonunda en önemli faktördür .

SQL Server, büyük bir sayı olduğunu tahmin ettiğinde kümelenmemiş dizinleri kullanmaz. ANAHTAR veya RID döngü işlemlerinin yapılması gerekeceğinden, bu tür tahminlerde yardımcı olacak indeksler (ve sütunlar) üzerindeki istatistikleri tutar.

İstatistiklerle ilgili 2 önemli şey var:

1. Histogram, SADECE en soldaki istatistik (dizin) sütunu için veri dağılımı hakkında bilgi depolar. Ayrıca, anahtar değerlerin çoklu sütun yoğunluğu hakkında bilgi depolar. Dolayısıyla, esasen, histogram, sadece en soldaki istatistik sütunu için veri dağılımını saklar.

2. SQL Server, tablo boyutuna bakılmaksızın histogramda en fazla 200 adım tutacaktır. Her bir histogram adımının kapsadığı aralıklar, tablo büyüdükçe artar, bu da büyük tablolar için "daha az doğru" istatistiklere yol açar.

   İndeks seçiciliğinin, yoğunluk ile ters orantılı olan bir metrik olduğunu unutmayın; yani bir sütunda ne kadar benzersiz değerler varsa, seçiciliği de o kadar yüksek olur.

Belirli sorgular çok sık çalışmadığında, bir dizin yerine sütun düzeyinde istatistikler oluşturmayı seçebilirsiniz. Sütun düzeyi istatistikleri, Sorgu Doktorunun daha iyi yürütme planları bulmasına yardımcı olur; bu yürütme planları, içerdiği dizin taramaları nedeniyle düşüktür. Aynı zamanda, istatistikler veri değiştirme işlemleri sırasında bir ek yük getirmez ve dizin bakımının önlenmesine yardımcı olurlar. Bu yaklaşım yalnızca nadiren yürütülen sorgular için işe yarar.

Bakın:

• Sütun İstatistikleri Optimize Edici'ye Kalen Delaney'den Bir Kenar Verin
• İstatistikler, Lanet olası Yalanlar ve İstatistikler - Statman nedir? Conor Cunningham tarafından

Not: Paul White veya Aaron Bertrand gibi biri , iyi sorunuza daha fazla renk sağlamak için ses çıkarabilir .

Veri miktarını sınırlayabilmeniz / alanlara bağlı olarak hızlı bir şekilde doğru verilere ulaşabilmeniz gerektiğinde bir endekse ihtiyacınız olduğunu söyleyebilirim.

İşlemleri mümkün olan en iyi şekilde yapabilmek için verilerin yapısını anlamak için iyileştiriciye ihtiyaç duyduğunuzda istatistiklere ihtiyacınız vardır.

Ne farkettim ki, filtrelenmiş istatistikler, verilerinizde planı ağır şekilde etkileyen çarpıklıklar olduğunda, örneğin yığın taşması durumlarında az sayıda kullanıcının çok sayıda mesajı olması nedeniyle yardımcı olur, bu nedenle kullanıcı başına yalnızca ortalama yayınların kullanılması gerçekten en iyi tahmin değildir. Böylece, kullanıcı adına göre userId'de filtrelenmiş bir istatistik oluşturabilir ve ardından SQL Server, bu kullanıcı adı sorguda olduğunda, bunun alacağı kullanıcı kimliği olduğunu ve bunun ne olduğunu anlayabilmesi gerektiğini bilmelidir. Gönderiler tablosundaki dizine eklenmiş alan, bu kimliğe sahip çok sayıda satır içerecektir, çünkü histogram oradadır. Ortalamalar ile bunu yapmak mümkün değildir.

Itzik Ben-Gan'dan 70-461 Eğitim kitabı

El ile istatistik oluşturmak için yalnızca birkaç neden olabilir. Bir örnek, bir sorgu yüklemesinde sütunlar arası ilişkilere sahip birden çok sütun içerdiğinde; Birden çok sütundaki istatistikler, sorgu planını iyileştirmeye yardımcı olabilir. Birden çok sütundaki istatistikler, tek sütun istatistiklerinde bulunmayan sütunlar arası yoğunlukları içerir. Ancak, sütunlar zaten aynı dizindeyse, çok noktalı virgül istatistik nesnesi zaten var, bu nedenle el ile ek bir tane oluşturmamanız gerekir.