Bir zaman boyutu tablosuna dizinleri nereye koymalı?

Bu web sitesinden dizinlerle ilgili Sorular ve Cevapları okuduktan sonra aklıma bir soru geldi.

Ya, daha düşük ayrıntı düzeyi gün olan bir zaman boyutu tablosu kullanıyorsa. Endeksleri nereye koymalı?

Sorudaki Randy Melder: “index” RDBMS'de ne anlama geliyor? dedim :

Bir dizini "içindekiler" olarak düşünün.

Zaman boyutu söz konusu olduğunda, zaman tablosu benzersiz bir yıl boyunca tüm günü saklıyorsa, çoğu veri araştırması belirli bir gün, belirli bir hafta, belirli bir ay veya belirli bir çeyrek için yapılabilir .

Sorum şu: Tüm bu alanlar için indeks konulmalı mı?

Günün benzersiz olduğunu varsayalım, bu yüzden bunun için dizinlerin kullanımını mükemmel bir şekilde anlıyorum. Ancak bir hafta kimliği 7 , bir aylık kimliği 30/31 , bir çeyrek kimliği az veya 120 kez olur .

• Bu alanlar için hala indeks konulmalı mı?
• Yine de faydalı olacak mı?

Size şunu soruyorum çünkü aynı soruda David Spillett şunları söyledi:

Çok fazla dizin eklemek elbette kötü bir optimizasyon olabilir, çünkü dizinleri depolamak için kullanılan fazladan alan (ve DB'niz birçok yazma işlemi görürse bunları korumak için IO yükü) biraz daha az optimum okuma sorgularından daha kötü bir sorun olabilir , bu yüzden aşırı yapma.

Peki zaman boyutu vakası için en iyi düşünceler nelerdir?

Yazma problemleri ile karşılaşmayacaksınız, çünkü bunun bir kez (veya yılda bir kez) yaratıldığını ve sonra dokunulmadığını düşünüyorum.

Ancak haftaya göre arama yapıyorsanız bir dizin kullanmak muhtemelen bir hinderance olacaktır ... Sorun, dizin kullanılıyorsa, önce bunu tarayabilir ve ardından her kaydı tablodan ayrı ayrı kapatabilirsiniz. kayıtların yaklaşık% 5-20'sinden fazlasını çekerek, tam bir masa taraması yapmak ve daha sonra umursadığınız kayıtları bırakmak daha hızlıdır.

İyi dağıtılmış veriler olduğunda bunun için optimize etmeyen büyük RDBMS'leri bilmiyorum. İyi dağıtılmış değilse, masaya histogramlar hesaplamak ve gerekebilir (örneğin, bir sütunda değerlerden biri zamanın% 95 oluşur, ancak diğer olası değerler de vardır) değil , ararken değeri için yer tutucu kullanın böylece sorgu optimize edici yürütme planı oluşturulurken aranan değere sahip olur.

Ben büyük olasılıkla olur değil haftanın endeksi günü. Dizinli okumalar veya tam tablo taramaları için yılın ay veya ayını dizine ekleyip eklemeyeceğimizi görmek için veritabanlarının belgelerini kontrol ediyorum. Varsa büyük olasılıkla DOY / yılın gününü endeksleyeceğim (zaten benzersiz endeksiniz gibi görünüyor)

Bir endeksin yararlı olması için benzersiz olması gerekmez, bu yüzden cevap bağlıdır . Sorgularınız dizinin varlığından yararlanıyorsa, değerli bir ek olabilir. Zaman sütunları ile ilgili özel bir kılavuz olması gerektiğini bilmiyorum. Bunlara diğer sütunlar gibi davranın ve sorguların kullanışlılığına göre dizine ekleyin.

Genel kural, dizin ne kadar seçici olursa (seçicilik bir sütundaki benzersiz değerlerin sayısının tablodaki satır sayısına bölünmesiyle elde edilir), bir sorgu varsa motorun dizini kullanması daha olasıdır where deyimindeki sütunu kullanır.

Bir sütunu dizine eklemeyi düşünüyorsanız, önce ve sonra dizine eklenen sütunu seçerek bir sorgu çalıştırmak ve yürütme planlarına bakmak, dizinin kullanılıp kullanılmadığını ve varsa, dizinin ne kadar yardımcı olduğunu bildirir. İdeal olarak, test için kullandığınız sorgu uygulamanız tarafından kullanılacak sorgudur.

Şimdiye kadar, temel kuralım, geliştirme veritabanlarım üzerinde çalışırken hiç endeks koymak değil. Üretim veritabanı büyüdükçe, veritabanı günlüğü kullanıyorum ve EXPLAINdizin oluşturmaya gerek duyulan şeyleri anlıyorum ve sonra yalnızca gerekli dizinleri oluşturuyorum. Bu, veritabanı kullanımı kademeli olarak arttığı sürece iyi çalışır ve dizin sayılarını düşük tutar.

Veritabanındaki verileri analiz ederken, genellikle üretimde yaygın olmayan istekleri hızlandırmak için ek dizinler eklemem gerekir. Bunu her zaman üretim veritabanının kopyalarında yaparım, bu nedenle bu dizinler asla üretime eklenmez.