Bir veritabanında yalnızca bir ek varsa, olası her sütun bileşimini dizine eklemek kötü mü?

Büyük seçim sorguları gerektiren bir raporlama sistemi üzerinde çalışıyorum, ancak yalnızca bir kez doldurulmuş bir veritabanına dayanıyorum. Veri tabanı yönetim sistemi Microsoft SQL Server 2017'dir. Muhtemelen böyle bir sistemi tasarlamak için daha iyi bir yol var, ama buna teorik olarak yaklaşalım.

Teorik olarak konuşma:

1. Çok büyük bir veritabanımız varsa (birkaç masada 150M + satır)
2. Ve veritabanının sadece bir kez doldurulacağını varsayabiliriz.

Her olası sütun kombinasyonunun dizine eklenmesinin bir seçim sorgusu üzerinde olumsuz bir performans etkisi olabilir mi?

Evet, ilk planın derlenme süresini etkileyecektir, çünkü optimizer dikkate alınacak verilere birçok ekstra erişim yoluna sahip olacaktır.

SQL Server 2017’de olduğunuzdan, bir kez yükleyip rapor çalıştırdığınızdan, neden yalnızca kümelenmiş bir sütun deposu dizini kullanmıyorsunuz?

Her olası sütun kombinasyonunu indeksleme ihtiyacınıza en uygun çözüm bu gibi görünüyor.

Sütun deposu dizinleri - Genel Bakış

Bir tabloda N sütununuz varsa, her olası sütun birleşimi 2 ^ N-1'dir (boş kümeyi kaldırarak). 1023 endeks anlamına gelecek 10 sütun için, 20 sütun için bir kuyruklu 1048575 endeksle sonuçlanıyoruz. Endekslerin çoğu asla kullanılmayacak, ancak optimize edici tarafından dikkate alınması gerekecektir. İyileştiricinin daha iyi bir dizin yerine en uygun alt dizini seçmesi mümkündür. Hangi indekslerin gerçekten faydalı olacağını bulmaya çalışmak yerine, her türlü endeks üretme yolunu izlemem.

EDIT düzeltilmiş olası dizin sayısı

Jeff'in işaret ettiği gibi (3,2,1) açıkça (1,2,3) olduğundan farklı olduğundan 2 ^ N'den (güç ayarı) daha kötüdür. N sütunları için, tüm sütunları N yollarıyla içeren bir dizindeki ilk konumu seçebiliriz. İkinci pozisyon için N-1 yöntemleriyle vs. Biz N ile son buluruz! tam boyutta farklı indeksler. Bu indekslerin hiçbiri bu sette başka bir indeks tarafından listelenmiyor. Ek olarak, daha kısa bir dizin ekleyemiyoruz, böylece herhangi bir tam dizinin kapsamına girmiyor. Bu nedenle indeks sayısı N! Bu nedenle, 10 sütun örneği 10 olur! = 3628800 endeksler ve 20 (tambur) 2432902008176640000 endeksler için. Bu gülünç derecede büyük bir sayıdır, her endeks için bir mm'lik bir parçayı bir noktaya koyarsak, tüm noktaların geçmesi bir 94 gün sürer. Hepsi ve hepsi, değil ;-)

Yok hayır.

"Her şeyi" dizine eklemek pratik değildir, ancak "çoğunu" dizine ekleyebilirsiniz.

İşte şey. Bir tabloda Nsütunlar varsa , olası dizinlerin sayısı N!. Bir tablonun 10 sütunu olduğunu varsayalım, o zaman sadece 10olası indeksleriniz yok, ama 10!. Yani ... 3.628.800 ... tek bir masada. Çok fazla disk alanı, disk G / Ç, önbellek ve arama süreleri.

Niye ya? Birkaç sebep:

• LightWight endeksleri genellikle önbelleğe alınır, bu da onları hızlı bir şekilde aydınlatmasını sağlar. 3 milyonu varsa, onlar önbelleğe alınmayacak.

• SQL optimizer, özellikle birleştirme kullanıldığında hangisinin daha iyi kullanılacağına karar vermek çok zaman alabilir.

• SQL optimizer, kapsamlı algoritmayı kullanmaktan vazgeçebilir ve bunun yerine sezgisel bir algoritmayı deneyebilir. Bu "optimalden daha az" olabilir. Örneğin, PostgreSQL, "8’den az tablo sorgusu" ve "8’den fazla tablo sorgusu" için farklı seçeneklere sahiptir.

• Endekslerin öbekten daha hafif olması gerekiyordu. Her şeyi dizine ekliyorsanız, dizin öbek kadar ağır olur ... dizinin amacını yitiren bir şey.

Hayır, muhtemelen SELECTsorgular üzerinde olumsuz bir etkisi olmaz , ancak

• Yüksek disk kullanımına neden olur.
• Bu olacak derece artması INSERTmaliyetleri.
• Endekslerinin çoğu hiç kullanılmayacak.
• Çoğu WHEREkoşul ifadeleri, özellikle daha karmaşık olanları olan endeksleri kullanmaz.
• Gerekli endekslerin sayısı, sütunların sayısı ile birlikte üssel olarak artacaktır. Örneğin, 8 sütununuz varsa, tüm olası kombinasyonlar için 256 endeks gerekir.