Чи в порядку сліпо додати пропущені індекси?

Я часто використовую SSMS для тестування моїх повільно зберігаються процедур на відсутність індексів. Кожного разу, коли я бачу "пропавший індекс (вплив xxx)", моя реакція на коліно - це просто створити новий індекс. Це призводить до швидшого запиту щоразу, наскільки я можу сказати.

Будь-яка причина, чому я не повинен продовжувати це робити?

Багато причин.

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

Приклад:

У вас є стіл з ColA, ColB, ColC.

На даний момент у вас індекс на ColA. Відсутній індекс DMV запропонує вам додати індекс (ColA, ColB). Це може бути правильним, але розумна річ - додати ColBяк другий ключ до існуючого індексу. В іншому випадку у вас є дублююче покриття та витрачений простір та накладні витрати.

Аналогічно, якщо у вас індекс увімкнено ColB INCLUDE (ColA), він може запропонувати індекс на ColB INCLUDE (ColC). Знову ж розумною справою є додавання ColCдо списку включення в існуючий індекс.

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

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

Якби не було проблем із додаванням усіх запропонованих індексів, тоді не було б потреби навіть пропонувати їх - вони будуть реалізовані автоматично.

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

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

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

3) Можливо, ви не бачите всієї картини. Особливо це стосується використання лише графічного плану та не перегляду XML, щоб побачити, чи запропоновано більше одного відсутнього індексу. Перший, показаний у графічному плані, не обов'язково є тим, що найбільше впливає на запит.

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

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

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