Endeks stratejileri hakkında bazı rehberleri nereden bulabilirim?

Çoğumuz muhtemelen veritabanı dizinlerini kullanmanın iyi olduğunu kabul edeceğiz. Çok fazla sayıda dizin ve performans gerçekte bozulabilir.

Genel bir kural olarak, hangi alanlar endekslenmelidir?
Hangi alanlar endekslenmemelidir?
Performans artışı sağlamak için bozulma değil, çok fazla sayıda ve yeterli sayıda endeks arasında denge kurulurken indeksleri kullanmanın kuralları nelerdir?

Kısa

"Çok fazla endeks" kuralı biraz yanıltıcı olduğunu düşünüyorum.

Uzun

Ortalama veritabanının% 98 civarında olduğu göz önüne alındığında (veya daha yüksek) okumaların optimize edilmesi gerekir. Örneğin, benzersiz bir dizin varsa INSERT bir okumadır. Ya da bir güncelleme NEREDE. Bir keresinde okuduğum bir yazma yoğun veritabanının bile hala% 85 okuduğunu okudum.

Sahip olduğun şey düşük kaliteli endeksleme. Örnekler:

• geniş kümelenmiş dizinler (özellikle SQL Server)
• monotonik olmayan kümelenmiş indeksli
• örtüşen indeksler (örneğin cold, colevecold, cole, colf)
• sorgularınız için işe yaramaz olan birçok tek sütun dizini (daha faydalı dizinlerle çakışan)
• DAHİL DEĞİLDİR, kapsayan değil (örneğin, tüm tek sütun dizinleri)
• ...

OLTP sistemlerinde bile indekslerin gerçek verilerinizden birkaç kat daha büyük olması oldukça tipiktir.

Genellikle ben ile başlar

• kümelenmiş dizin (genellikle PK)
• benzersiz dizinler (kısıtlamalar değil, bunlar kapsamaz)
• yabancı anahtar sütunları

Sonra bakardım:

• Yaygın sorgular ve neye ihtiyacım olduğunu görün. Her saniye çalışan bir sorgunun ayarlanması gerekir. 04:00 pazarındaki rapor bekleyebilir.
• SQL Server ile ağırlıklı eksik indeks DMV'ler

Bunu söyleyerek, bir sistemi ayarlamak için işlerin nasıl paniklediğini (10 milyar satır sonra) gördükten sonra, bazı sistemler için bu kuralları çiğnedim. Ama düşünün asla değil bu yüzden yapıyorum neden göstermek olabilir sürece indeksleme.

Veritabanı kullanımınızı profillemeli ve yüklemeli ve eksik dizinler nedeniyle veya çok fazla dizin nedeniyle darboğazı tanımlamalısınız. O zaman uygun dizini seçmelisiniz - ve bu özel veritabanı indeksleme teknikleri hakkında iyi bir bilgi gerektirir.

Oldukça basit, hangi dizinde seçileceği ve neden Gail Shaw tarafından yazılacağı üzerine yazılmış en iyi makalelerden biri. Sen tıklayarak makaleler bulabilirsiniz burada

İstediğiniz soruya 50 farklı yolla cevap verilebilir. Gerçekten hepsi, sahip olduğunuz verilere ve nasıl sorgulanacağına bağlı. Genel bir kural, yığınları önlemek için her zaman her tabloda kümelenmiş bir dizininiz olması gerektiğidir. Kümelenmiş dizinler tipik olarak olabildiğince küçük olmalıdır. Tabloda kümelenmiş bir dizin varsa, kümelenmemiş dizinin yaprak sayfalarındaki tüm dizin kayıtları, yer işareti aramaları için ilgili kümelenmiş dizinin kayıt değerini saklar. Bir tablo bir öbekse, SQL yer işareti aramaları için benzersiz bir tanımlayıcı oluşturur. 8 ya da 16 bayt olduğunu hatırlayamıyorum. Bu daha sonra bir INT diyerek çok daha büyük bir veri türü olabilir. Bir yığın masada kümelenmemiş 8 dizin olduğunu hayal edin.

Buraya farklı veritabanlarının farklı stratejiler gerektirdiğini eklemek istiyorum. Mesela MySQL ile w / InnoDB ve PostgreSQL'i karşılaştıralım.

InnoDB'nin

InnoDB tabloları temelde, dizin girişine satır bilgisini içerecek şekilde genişletilen birincil anahtarın bir b-ağacı indeksidir. Fiziksel sipariş taramaları desteklenmez ve tüm taramalar mantıksal sırada gerçekleşir. Bu iki şey demektir:

1. Innodb'deki sıralı bir tarama çok fazla rasgele disk G / Ç üretir ve

2. Birincil anahtar endeksinin, bir ikincil indeks kullanıp kullanmadığından bağımsız olarak geçilmesi gerekir.

3. Birincil anahtar aramaları bu modelde diğer tüm yaklaşımlardan daha hızlıdır.

Bu durumda, çok sayfalı tablolarda yeterli alan dizini oluşturmak çok önemlidir. Tipik kural, filtrelemek istediğiniz her şeyi dizindir.

PostgreSQL

PostgreSQL, yığın dosyalarının bir yığın boş alandan tahsis edildiği dosya başına bir tablo (bazı tablolar çok sayıda dosya olabilir) kullanır. Fiziksel sipariş taramaları desteklenir. Mantıksal sipariş taramasının çalışması için bir dizin eklenmelidir.

PostgreSQL'deki birincil anahtarlar temelde hiçbir değerin NULL olamayacağı benzersiz endekslerin alt kümesidir. UNIQUE kısıtlamaları örtük dizinler kullanılarak yapılır ve dizinde olası farklı işlemlerle başka dizin türleri de desteklenir.

Bunun anlamı:

1. Birincil anahtar aramalar, bir indeks dosyasına ve bir tablo dosyasına isabet eden oldukça büyük bir tablerequire olduğunu varsayar . Bu, MySQL'in yalnızca dizinin geçilmesi ve satırın dizinde bulunması gerektiği yaklaşımından önemli ölçüde daha yavaştır.

2. Fiziksel sıra taramaları çok daha iyi performans gösterir ve önemli sayıda satırın işleneceği rasgele disk G / Ç'yi azaltır.

3. İkincil dizin taramaları, MySQL'lerden daha iyi performans gösterir, çünkü tablonun fiziksel kısmına ulaşmak için yalnızca bir indeksin geçilmesi gerekir.

Bu modelde, endeksler sıklıkla gereklidir, ancak planlayıcı, bir endeks kullanırken ne zaman daha fazla özgürlüğe sahiptir ve bir tane kullanmamanın etkileri genellikle daha az şiddetlidir. Tablolar daha genel olarak optimize edilmiştir (pkey aramalarında uzmanlaşmak yerine) ve bu yüzden daha az endeks gereklidir.

TL; DR

RDBMS'nizi bilin.

Oracle 11.2 Kavramlar Kılavuzu'ndan:

• Dizinlere Genel Bakış

11.2 Performans Ayarlama Kılavuzundan:

• Dizine Eklenecek Sütun ve İfadeleri Seçme
• Dizin ve Kümeleri Kullanma

11.2 Yönetici Kılavuzu'ndan:

• Dizinleri Yönetme Yönergeleri

Yukarıdaki bağlantıların hepsinde bile, Kimberly Tripp'in indekslerin bakımı, beslenmesi ve kullanımıyla ilgili neler yazdığına bakmanız gerekir .

Yeni başlayanlar için, Kimberly'nin endeksle ilgili blog gönderileri koleksiyonunu bu linki takip edin . Tarayıcı pencerenizin sol tarafındaki "Bu sayfada" ve "Kategoriler" araçlarını kullanarak belirli konuları keşfedebilirsiniz.

Burada çok fazla bilgi var, ancak bundan korkmayın.

Kimberly'nin Hakkında sayfası burada

SQL Server ile çalışıyorsanız, faydalı bulabileceğiniz bazı kaynaklar:

• http://www.toadworld.com/platforms/sql-server/w/wiki/9624.indexing.aspx
• http://www.sql-server-performance.com/category/tips/index/
• http://sqlfool.com/summit2010/
• http://sqlfool.com/2011/06/index-defrag-script-v4-1/