Büyük index INCLUDE alanları sistem performansını nasıl etkiler?


15

Bu soru, bir kaplama dizininde varchar(2000)bir ile SQL Server dizin performansı hakkındadır INCLUDE.

Yavaş ve kararsız bir veritabanı uygulamasında performansı artırmaya çalışıyorum. Bazı durumlarda, veri gibi multple dize operasyonları gibi sorgu ile büyük varchar dizeleri üzerinden erişilen SUBSTRING(), SPACE()ve DATALENGTH(). İşte basitleştirilmiş erişim örneği;

update fattable set col3 =  
   SUBSTRING(col3,1,10) + '*' + 
   SUBSTRING(col3,12,DATALENGTH(col3)-12)
from fattable where substring(col3,10,1) = 'A' and col2 = 2

Şema şöyle görünür:

CREATE TABLE [dbo].[FatTable]( 
    [id] [bigint] IDENTITY(1,1) NOT NULL, 
    [col1] [nchar](12) NOT NULL, 
    [col2] [int] NOT NULL, 
    [col3] [varchar](2000) NOT NULL, ... 

Aşağıdaki metin büyük metin sütununda bir kaplama alanı ile tanımlanmıştır.

CREATE NONCLUSTERED INDEX [IndexCol2Col3] ON [dbo].[FatTable]  ( [col2] ASC ) 
    INCLUDE( [col3] )

Okuduğum kadarıyla büyük veri alanlarını bir dizine koymak KÖTÜ. Disk belleği ve disk boyutunun dizin performansı üzerindeki etkisini tartışan http://msdn.microsoft.com/en-us/library/ms190806.aspx dahil birkaç makale okudum . Bununla birlikte, sorgu planı kesinlikle örtme endeksini kullanır. Bunun sistem yükü açısından bana ne kadara mal olacağını belirlemek için yeterli bilgim yok. Genel olarak, sistemin kötü performans gösterdiğini biliyorum ve bunun sorunlardan biri olduğundan endişeliyim. Sorular:

  • Bu varchar(2000)sütunu dizine koymak INCLUDEhiç iyi bir fikir midir?

  • Yana INCLUDEalanları yaprak düğümlerin saklanır, bunlar kadar etkisi endeksi performansını var mı?

Güncelleme: Mükemmel cevaplar için teşekkürler! Bu bazı yönlerden haksız bir sorudur - siz söylediğiniz gibi, gerçek istatistikler ve profil oluşturma olmadan mutlak bir doğru cevap yoktur. Pek çok performans sorunu gibi, sanırım cevap "bağlıdır".


Gerçek değerler ne kadardır? Bir VARCHAR(2000)hangi tipik mağazaları sadece on karakter bir şeydir; kayıt başına 2.000 bayt katı başka bir şeydir.
Tüm

Sadece bir gözlem: Burada "koklayan" bir şey, büyük sütunun 1) serbest metin içerebileceğidir, bu durumda sorgular bir FULLTEXT indeksi veya 2) "insan tarafından okunabilir" kodlanmış veri (örn. Geniş akıllı) kullanmak için yeniden yazmalardan yararlanabilir anahtarlar (VIN gibi) ayrı ayrı sütunlara veya INDEX'lerle kalıcı hesaplanmış sütunlara bölmekten yararlanabilir. Başka bir deyişle, zeka akışı ve veri değişiklikleri iyi tasarlanmamıştır.
Graeme

1
Evet # Grame, burada kötü bir koku var - sanırım buna "miras" deniyor. Bu veritabanlarında çok sayıda sorun var.
RaoulRubin

Yanıtlar:


14

Hiç büyük bir kelime, ama genel olarak hayır, bir DAHİL ETME alanına varchar (2000) alanı koymam.

Ve evet, verilerin sayfa düzeyinde depolanma biçimi, dizinin nasıl kullanıldığına bağlı olarak dizinin performansını ciddi şekilde etkileyebilir.

Mesele şu ki, bir sayfaya ne kadar çok veri satırı sığdırabiliyorsanız, o kadar az sayfaya erişilmesi gerekir, sisteminiz daha hızlıdır. Gerçekten büyük bir sütun eklemek, bir sayfada daha az bilgi depolanması anlamına gelir; bu nedenle, aralık aramaları veya taramalarda, verileri almak için daha fazla sayfanın okunması gerekir ve bu da işleri yavaşlatır.

Sorgunuzda veya sisteminizde bir sorun olup olmadığından emin olmak için, okumaları, özellikle de sorgunun kullandığı sayfa sayısını izlemeniz gerekir.


Teşekkürler Grant. Başka bir yorumdan bahsettiğim gibi, iyi performans bilgisi azdır, bu nedenle soyut soru. Sayfa boyutu performans maliyetlerini izleme konusunda deneyimim yok. Benim önsezim bu bir problem, bazı istatistikler elde edip edemeyeceğimi görecek.
RaoulRubin

1
sorgu için istatistik GÇ ayarlandığında size çok şey söylenir, mantıksal okumalar erişilen sayfa sayısını gösterir. Ayrıca genel performans bilgisi almak için saniye / perfmon sayaçlarından okuyabilirsiniz.
Grant Fritchey

6

Geçerli kümelenmiş dizin anahtarını inceleyebilir ve col2bunun yerine kümelenmiş dizin anahtarını yapabilir misiniz? Bu şekilde, kapsayan 'içerme' davranışını elde edersiniz (çünkü kümelenmiş endeksler her zaman verileri içerir). Bu, elbette birçok kişiye tabidir ifve butyine de düşünmeye değer. Elbette, geçerli kümelenmiş dizin bir kısıtlamayı zorunlu kılıyorsa (birincil anahtar, benzersiz), söz konusu kısıtlamanın kümelenmemiş bir dizine taşınması gerekir.


PK ile ilgili öneriniz harika bir fikir, ancak bu durumda uygulayamayacağım - diğer sorgular için mevcut PK gerekli. (Bu, alet kutusunda tutacağım bir tekniktir!)
RaoulRubin

4

Cevaplamak zor. Her şey sizin okuma: yazma oranınıza bağlı olacaktır. Birlikte verilen sütunu içeren veya içermeyen bir iş yükünü test ettiniz veya bir test sisteminde tüm iş döngüsünü simüle ettiniz mi? Onsuz arama çok maliyetli olabilir, ancak verileri okuduğunuzdan daha sık güncelliyorsanız, sorun olmayabilir.


Genel okuma ve güncelleme çoğunlukla dengelidir. Organizasyon ve gizlilik sorunları, yararlı istatistikler ve gerçekçi testler almayı zorlaştırır. Çoğunlukla kör olarak uçtuğumuz için, şeylere soyut bir bakış açısından bakmalıyız (dolayısıyla bu soru). Test, üretimde değişikliklerin itilmesi ve sonuçların gözlemlenmesi anlamına gelecektir - çok riskli.
RaoulRubin

2
Ve okumaların çoğu aslında bu VARCHAR(2000)sütunu mu çekiyor? Bu sütun ise Grant anlaşılacağı gibi değil sorgular bir sürü kullanılan veya gerçekten değil mi ederken gerekmektedir, ancak depolama için ödeme yaparken muhtemelen arama için bedel ödemek daha iyi olacak, arar için sorunlara yol açmaktadır . Yine, çitin hangi tarafında olmanız gerektiğini söylemek gerçekten zor, çünkü gerçekten herhangi bir spesifikasyona sahip değiliz (ve test edemediğiniz için daha da zor - bunu düzeltmek için çaba göstermelisiniz).
Aaron Bertrand

3

Bu partiye geç kaldığımı biliyorum, ancak tam olarak alt dizgi (col3,10,1) gibi satırları bulmak için kullanılan ifadeleri dizine eklerdim. Eğer tüm col3 kullanılırsa, ben CHECKSUM (col3) dizin olurdu (tabii ki çarpışmalar olabilir anlamak).

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.