SQL Server'da bir bit alanını indekslemeli miyim?

Bir noktada, düşük kardinaliteye (düşük sayıda farklı değer) sahip bir alanı indekslemenin gerçekten yapmaya değmediğini okuduğumu hatırlıyorum. Bunun nedenini anlamak için indekslerin nasıl çalıştığını yeterince bilmediğimi itiraf ediyorum.

Peki ya içinde 100 milyon satır olan bir tablom varsa ve bit alanının 1 olduğu kayıtları seçiyorsam? Ve diyelim ki herhangi bir zamanda, bit alanının 1 olduğu (0'ın aksine) yalnızca bir avuç kayıt vardır. Bu bit alanını indekslemeye değer mi değil mi? Neden?

Tabii ki sadece test edip uygulama planını kontrol edebilirim ve bunu yapacağım ama arkasındaki teoriyi de merak ediyorum. Kardinalite ne zaman önemli ve ne zaman önemli değil?

SQL'de bir indeksin ne olduğunu düşünün - ve indeks aslında diğer bellek parçalarını (yani satırları gösteren işaretçiler) işaret eden bir bellek yığınıdır. Dizin, kullanıma bağlı olarak dizinin bazı bölümlerinin bellekten yüklenip kaldırılabilmesi için sayfalara bölünmüştür.

Bir dizi satır istediğinizde, SQL, satırları tablo taramasından (her satıra bakarak) daha hızlı bulmak için dizini kullanır.

SQL kümelenmiş ve kümelenmemiş dizinlere sahiptir. Kümelenmiş dizinler hakkındaki anlayışım, benzer dizin değerlerini aynı sayfada gruplandırmalarıdır. Bu şekilde, bir dizin değeriyle eşleşen tüm satırları sorduğunuzda, SQL bu satırları kümelenmiş bir bellek sayfasından döndürebilir. Bu nedenle, bir GUID sütununu dizine eklemeye çalışmak kötü bir fikirdir - rastgele değerleri kümelemeye çalışmazsınız.

Bir tamsayı sütununu indekslediğinizde, SQL'in indeksi her indeks değeri için bir dizi satır içerir. 1 ile 10 arasında bir aralığınız varsa, o zaman 10 dizin işaretleyiciniz olur. Kaç satır olduğuna bağlı olarak bu farklı şekilde sayfalanabilir. Sorgunuz "1" ile eşleşen dizini ararsa ve sonra Ad "Fred" i içeriyorsa (Ad sütununun dizinlenmediğini varsayarak), SQL "1" ile eşleşen satır kümesini çok hızlı bir şekilde alır, ardından geri kalanını bulmak için tablo tarar.

Öyleyse, SQL'in gerçekten yaptığı şey, yinelemesi gereken çalışma kümesini (satır sayısını) azaltmaya çalışmaktır.

Bir bit alanını (veya bazı dar aralıkları) dizine eklediğinizde, çalışma kümesini yalnızca bu değerle eşleşen satırların sayısı kadar azaltırsınız. Eşleşen az sayıda satırınız varsa, çalışma kümenizi çok azaltır. 50/50 dağılımlı çok sayıda satır için, endeksi güncel tutmaya kıyasla çok az performans kazancı sağlayabilir.

Herkesin test etmeyi söylemesinin nedeni, SQL'in tablo taramanın daha hızlı olduğuna karar verirse bir dizini göz ardı edebilecek çok akıllı ve karmaşık bir optimize edici içermesi veya bir sıralama kullanması veya bellek sayfalarını iyi istediği şekilde düzenleyebilmesidir.

Bu soruya başka bir yolla rastladım. İfadenizin yalnızca bir avuç kayıttan 1 değerini aldığını (ve ilgilendiklerinizi) varsayarsak, filtrelenmiş bir dizin iyi bir seçim olabilir. Gibi bir şey:

create index [IX_foobar] on dbo.Foobar (FooID) where yourBitColumn = 1

Bu, sorgunuzda bir yüklem olduğunda optimize edicinin yeterince akıllı olduğu, önemli ölçüde daha küçük bir dizin oluşturacaktır.

Sadece birkaç bit alanı 1 olarak ayarlanmış 100 milyon kayıt? Evet, bit alanını indekslemenin kesinlikle bit = 1 kayıtlarını sorgulamayı hızlandıracağını düşünüyorum. Dizinden logaritmik arama süresi almalı ve sonra sadece bit = 1 kayıtları olan birkaç sayfaya dokunmalısınız. Aksi takdirde, 100 milyonluk kayıt tablosunun tüm sayfalarına dokunmanız gerekir.

Yine de, kesinlikle bir veritabanı uzmanı değilim ve önemli bir şeyi kaçırıyor olabilirim.

Dağıtımınız oldukça biliniyorsa ve dengesizse, örneğin satırların% 99'u bit = 1 ve% 1'i bit = 0 ise, bit = 1 ile bir WHERE cümlesi yaptığınızda, tam bir tablo taraması yaklaşık olarak aynı anda olacaktır. dizin taraması. Bit = 0 olan hızlı bir sorgu istiyorsanız, bildiğim en iyi yol, WHERE bit = 0 cümlesi ekleyerek filtrelenmiş bir dizin oluşturmaktır. Bu şekilde, bu dizin yalnızca% 1 satırını saklayacaktır. Sonra bir WHERE bit = 0 yapmak, sorgu iyileştiricisinin bu dizini seçmesine izin verir ve ondan gelen tüm satırlar bit = 0 olur .

SADECE bir sütunu kendi başına endeksleyeceğimi düşünmüyorum, ancak bileşik bir dizinin parçası olarak bit sütunlarını dahil etmek çok yaygındır.

Basit bir örnek, uygulamanız neredeyse her zaman aktif müşterileri aradığında, yalnızca soyad yerine ACTIVE, LASTNAME üzerinde bir dizin olabilir.

Okumadıysanız, Jason Massie geçenlerde bu konuyu tartışan bir makale yazdı.

http://statisticsio.com/Home/tabid/36/articleType/ArticleView/articleId/302/Never-Index-a-BIT.aspx

Düzenleme: Yeni makale konumu - http://sqlserverpedia.com/blog/sql-server-bloggers/never-index-a-bit

Önceki "Yeni" makale konumu için geri dönüş makinesi: http://web.archive.org/web/20120201122503/http://sqlserverpedia.com/blog/sql-server-bloggers/never-index-a-bit/

Yeni SQL Server Pedia konumu, Kenneth Fisher'ın bu konuyu tartışan yeni bir makalesi olan Toadworld'dur:

http://www.toadworld.com/platforms/sql-server/b/weblog/archive/2014/02/17/dba-myths-an-index-on-a-bit-column-will-never-be- used.aspx

geri dönüş makinesi: http://web.archive.org/web/20150508115802/http://www.toadworld.com/platforms/sql-server/b/weblog/archive/2014/02/17/dba-myths-an -index-on-a-bit-sütun-asla-kullanılmayacak.aspx

Elbette buna değer, özellikle verileri bu değere göre almanız gerekiyorsa. Normal bir matris kullanmak yerine seyrek bir matris kullanmaya benzer.

Artık SQL 2008 ile bölümleme işlevlerini kullanabilir ve bir dizine giren verileri filtreleyebilirsiniz. Önceki sürümlerin dezavantajı, dizinin tüm veriler için yapılmasıdır, ancak bu, ilginç değerleri ayrı bir dosya grubunda depolayarak optimize edilebilir.

Başkalarının da söylediği gibi, bunu ölçmek isteyeceksiniz. Bunu nerede okuduğumu hatırlamıyorum, ancak bir dizinin etkili olabilmesi için bir sütunun çok yüksek kardinaliteye (yaklaşık% 95) sahip olması gerekir. Bunun için en iyi testiniz, dizini oluşturmak ve BIT alanının 0 ve 1 değerleri için yürütme planlarını incelemektir. Yürütme planında bir dizin arama işlemi görürseniz, dizininizin kullanılacağını bilirsiniz.

Yapmanız gereken en iyi şey, temel bir SELECT * FROM tablosu WHERE BitField = 1 ile test etmektir; sorgulayın ve uygulamanız için gerçekçi bir sorgu elde edene kadar işlevselliği adım adım yavaşça oluşturun, dizin aramasının hala kullanıldığından emin olmak için her adımda yürütme planını inceleyin. Kuşkusuz, bu uygulama planının üretimde kullanılacağına dair bir garanti yok, ancak iyi bir şans var.

Bazı bilgiler sql-server-performance.com forumlarında ve atıfta bulunulan makalede bulunabilir.

"Bir noktada, düşük kardinaliteye (düşük sayıda farklı değer) sahip bir alanı indekslemenin gerçekten yapmaya değmediğini okuduğumu hatırlıyorum"

Çünkü SQL Server, dizini okumaktan ziyade sadece bir tablo taraması yapmak neredeyse her zaman daha verimli olacaktır. Yani temelde dizininiz asla kullanılmayacak ve onu korumak israftır. Diğerlerinin söylediği gibi, bileşik bir endekste sorun olmayabilir.

Amacınız, bit alanı değerinin '1'e eşit olduğu kayıtları daha hızlı sorgulamaksa, temel tablonuzun yalnızca bit alanınızın' 1'e eşit olduğu kayıtları içeren dizine alınmış bir görünümünü deneyebilirsiniz. Kurumsal sürümde, bir sorgu, sorgu performansını artırmak için belirtilen bir tablo yerine dizine alınmış bir görünümden yararlanabiliyorsa, görünümü kullanacaktır. Teoride bu, yalnızca '1' bit alanı değerine sahip kayıtları arayan seçme sorgularının hızını artıracaktır.

http://www.microsoft.com/technet/prodtechnol/sql/2005/impprfiv.mspx

Bütün bunlar, Microsoft SQL Server 2005 Enterprise olduğunuzu varsayar. Aynısı 2008 için de geçerli olabilir, bu sürüme aşina değilim.

Bir dizinin arzu ettiğiniz etkilere sahip olup olmadığını öğrenmek istiyorsanız: tekrar test edin ve test edin.

Genel olarak, bir dizini korumanın maliyeti nedeniyle tablonuzu yeterince daraltmayan bir dizin istemezsiniz. (maliyet> kar). Ama sizin durumunuzdaki indeks tabloyu ikiye bölecekse, bir şey kazanabilirsiniz ama onu masaya koymak. Her şey tablonuzun tam boyutuna / yapısına ve onu nasıl kullandığınıza (okuma / yazma sayısı) bağlıdır.

Kendi başına hayır, çünkü çok az seçicilikle sonuçlanıyor. Bileşik bir endeksin parçası olarak. büyük olasılıkla ancak diğer eşitlik sütunlarından sonra.

Sen olamaz endeksi SQL Server 2000'de bir bit alanını anda Books Online'da belirtildiği gibi:

bit

Tam sayı veri türü 1, 0 veya NULL.

Uyarılar

Bit türündeki sütunlarda dizin olamaz.

Evet, milyonlarca satırdan yalnızca bir avuç satırınız varsa, bir dizin yardımcı olacaktır. Ama bu durumda yapmak istiyorsanız, sütun a yapmalısınız tinyint.

Not : Enterprise Manager bit sütununda dizin oluşturmanıza izin vermez. Dilerseniz, bir bit sütununda manuel olarak da bir dizin oluşturabilirsiniz:

CREATE INDEX IX_Users_IsActiveUsername ON Users
(
   IsActive,
   Username
)

Ancak SQL Server 2000 aslında böyle bir indeksi kullanmaz - indeksin mükemmel bir aday olacağı bir sorgu çalıştırır, örneğin:

SELECT TOP 1 Username 
FROM Users
WHERE IsActive = 0

SQL Server 2000 bunun yerine dizin yokmuş gibi davranarak bir tablo taraması yapar. Sütunu bir tinyint olarak değiştirirseniz, SQL Server 2000 bir dizin araması yapacaktır . Ayrıca aşağıdaki kapsanmayan sorgu:

SELECT TOP 1 * 
FROM Users
WHERE IsActive = 0

Bir dizin araması ve ardından bir yer imi araması gerçekleştirecektir.

SQL Server 2005, bit sütunlarındaki dizinler için sınırlı desteğe sahiptir. Örneğin:

SELECT TOP 1 Username 
FROM Users
WHERE IsActive = 0

kaplama indeksi aracılığıyla bir indeks aramasına neden olur. Ancak kapsanmayan dava:

SELECT TOP 1 * 
FROM Users
WHERE IsActive = 0

bir indeks aramaya ve ardından bir yer imi aramasına neden olmaz, indeks aramanın ardından bir yer imi araması yapmak yerine bir tablo taraması (veya kümelenmiş indeks taraması) gerçekleştirir.

Deney ve doğrudan gözlemle doğrulanmıştır.

çok geç cevap ...

Evet, SQL CAT ekibine göre faydalı olabilir (güncellendi, konsolide edildi)

Bu yaygın bir sorgu mu? "Bir avuç" kayıt ararken buna değer olabilir, ancak diğer satırlarda size pek yardımcı olmayacaktır. Verileri tanımlamanın başka yolları var mı?

Önem faktörlerinden biri, diğeri ise dizinin verilerinizi ne kadar iyi böldüğüdür. Yaklaşık yarım 1'leriniz ve yarım 0'larınız varsa, o zaman yardımcı olacaktır. (Bu dizinin başka bir dizinden daha iyi bir yol olduğunu varsayarsak). Ancak, ne sıklıkla ekleyip güncelliyorsunuz? SELECT performansı için dizin eklemek INSERT, UPDATE ve DELETE performansına da zarar verir, bu yüzden bunu aklınızda bulundurun.

Diyorum ki, 1'den 0'a (veya tersi)% 75 ila% 25'ten daha iyi değilse, zahmet etmeyin.

öncesi ve sonrası yanıt süresini ölçün ve buna değip değmediğini görün; teorik olarak dizine alınmış alanları kullanan sorgular için performansı iyileştirmelidir, ancak gerçekten doğru / yanlış değerlerin dağılımına ve ilgilendiğiniz sorgulara dahil olan diğer alanlara bağlıdır.

Ian Boyd, SQL 2000 için Enterprise Manager aracılığıyla bunu yapamayacağınızı söylediğinde haklıdır (T-SQL aracılığıyla oluşturmaya ilişkin notuna bakın.

Burada sorgulamak için akıllı olmalısınız, eğer sisteminizde true yükü daha fazlaysa ve tüm gerçek değerleri kontrol etmek istiyorsanız, sütununuzdaki yük değerini bilmelisiniz ve sorgunuzu yanlış olmadığını kontrol etmek için yazın .. çok yardımcı olacaktır. , bu sadece hile.