Як великі поля з індексом INCLUDE вплинуть на продуктивність системи?

Це питання про продуктивність індексу SQL сервера з varchar(2000)як INCLUDEв індексі накриття.

Я намагаюся підвищити продуктивність у повільному та нестабільному додатку до бази даних. У деяких випадках доступ до даних здійснюється через великі рядки VARCHAR, з запитами , включаючи multple строкових операцій , як SUBSTRING(), SPACE(), і DATALENGTH(). Ось спрощений приклад доступу;

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

Схема виглядає приблизно так:

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, ... 

Визначений наступний індекс із полем покриття на великому текстовому стовпчику.

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

З того, що я прочитав, це BAD ставити великі поля даних в індекс. Я читав кілька статей, серед яких http://msdn.microsoft.com/en-us/library/ms190806.aspx, в яких обговорюється вплив підкачки та розміру диска на продуктивність індексу. При цьому, план запитів, безумовно, використовує індекс покриття. У мене недостатньо інформації, щоб визначити, скільки це насправді коштує мені з точки зору завантаження системи. Я знаю, що в цілому система працює погано, і я стурбований тим, що це одне з питань. Запитання:

• Чи ставити цей varchar(2000)стовпець в індекс INCLUDEзавжди корисною ідеєю?

• Оскільки INCLUDEполя зберігаються у вузлах листів, чи мають вони великий показник впливу показника?

Оновлення: Дякую за чудові відповіді! Це в чомусь несправедливе запитання - як ви кажете, не існує абсолютної правильної відповіді без фактичної статистики та профілювання. Як і стільки питань щодо продуктивності, я думаю, що відповідь "це залежить".

Колись це велике слово, але, загалом, ні, я б не вводив поле varchar (2000) у ВКЛЮЧЕНО.

Так, спосіб зберігання даних на рівні сторінки може серйозно вплинути на ефективність індексу, залежно від того, як використовується індекс.

Вся справа в тому, що чим більше рядків даних можна вписувати на сторінку, тим менше сторінок доводиться отримувати, тим швидше ваша система здебільшого швидша. Додавання дійсно великого стовпця означає менше інформації, що зберігається на сторінці, тому, у випадку пошуку діапазону чи сканування, для відновлення даних потрібно прочитати більше сторінок, що серйозно уповільнить роботу.

Щоб точно знати, чи це проблема у вашому запиті чи у вашій системі, вам слід буде стежити за показаннями, особливо за кількістю сторінок, якими використовується запит.

Чи можете ви переглянути поточний кластерний індексний ключ і, можливо, зробити col2 кластерний індексний ключ замість цього? Таким чином ви отримуєте поведінку покриття "включити" (оскільки кластерні індекси завжди "включаючи" все) без дублювання даних. Це, звичайно, підпорядковане багатьом ifі but, тим не менш, можливо, варто задуматися. Звичайно, якщо поточний кластерний індекс застосовує обмеження (первинний ключ, унікальний), зазначене обмеження потрібно буде перенести в некластеризований індекс.

Важко відповісти. Все залежатиме від співвідношення читання та запису. Ви протестували навантаження чи моделювали цілий бізнес-цикл на тестовій системі, із включеним стовпцем та без нього? Пошук без нього може коштувати дорого, але якщо ви оновлюєте дані частіше, ніж ви їх читаєте, це може бути нормально.

Я знаю, що я запізнююся на цю партію, але я б індексував саме вирази, які використовуються для розміщення рядків, наприклад, підрядка (col3,10,1). Якщо весь col3 коли-небудь буде використаний, я би індексував CHECKSUM (col3) (розуміючи, що, звичайно, можуть бути зіткнення).