Вплив індексу на оператори оновлення, коли стовпець оновлення не знаходиться в індексі

Я постійно бачу, як люди кажуть, що індекси сповільнюються update, deleteі insert. Це використовується як вислів ковдри, як би абсолютне.

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

У SQL Server, і я вважаю / припускаю більшість інших СУБД, ваші індекси створюються на основі визначених вами стовпців. Вставки та видалення завжди впливатимуть на весь рядок, тому немає ніякого способу, що вони не вплинуть на індекс, але оновлення здаються дещо унікальнішими, вони можуть впливати лише на певні стовпці.

Якщо у мене є стовпці, які не включені до жодного індексу, і я їх оновлюю, чи вони сповільнені лише тому, що я маю індекс у інших стовпцях цієї таблиці?

Наприклад, скажіть, що в моїй Userтаблиці я маю один або два індекси, первинним ключем яких є стовпець Ідентифікація / Автоматичне збільшення та, можливо, інший у якомусь стовпчику іноземного ключа.
Якщо я оновлюю стовпець без індексу безпосередньо на ній, наприклад скажімо, їх номер телефону чи адресу, чи це оновлення сповільнено, оскільки в інших таблицях в будь-якій ситуації є індекси в цій таблиці? Стовпці, які я оновлюю, не містяться в індексах, тому логічно, індекси не слід оновлювати, чи не так? Якщо що-небудь, я думаю, що вони прискорені, якщо я використовую індекси у пункті WHERE.

Ви правильні, що оновлення неіндексованого стовпця не призведе до змін індексів. У простому випадку також не було б загального впливу на стіл.

Якщо запит може використовувати Index для пошуку даних, він може прискорити пошук, але точна поведінка (залежно від вашої марки SQL) може відрізнятися від інших марок SQL. (Я в основному використовую Microsoft SQL Server.)

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

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

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

Незважаючи на те, що ваше запитання пов'язане з ефективністю, існує кілька інших можливих проблем щодо додавання індексів, включаючи, але не обмежуючись ними:

1. Час, необхідний для створення індексу, може призвести до блокування під час додавання індексу до таблиці. Замок дуже короткий, і, швидше за все, не створить великої проблеми.

2. Зміни індексу призводять до того, що плани виконання недійсні для будь-яких планів, на які посилається нижча таблиця. Коли ці плани виконання будуть перекомпільовані, ефективність може змінитись негативно для деяких запитів.

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

4. Новий індекс може призвести до зміни порядку виконання, що призведе до можливих тупикових ситуацій, які раніше не відбулися.

Якщо операція оновлення націлена на неіндексований стовпчик фіксованого розміру (наприклад, ціле число), це не повинно бути повільним, загалом кажучи, але порівняно з оператором select, оновлення має бути врешті записане і на повільний диск.