Викидання невикористаних індексів - Оцінка несподіваних небезпек

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

1. Перш ніж ми скинемо індекс, ми повинні переконатися, чи він не застосовує обмеження унікальності, оскільки оптимізатору запитів може знадобитися цей індекс для існування.
2. Щоразу, коли створюється індекс, на SQL Server створюється також статистика, пов'язана з цим індексом. Запит може не використовувати індекс, але він може використовувати його статистику. Тож ми можемо зіткнутися з ситуацією, після падіння індексу певна ефективність запиту стає дуже поганою. SQL Server не зберігає статистику використання статистики. Хоча в нашій базі даних увімкнена функція "Автоматична статистика", я не знаю, яким параметрам потрібно відповідати всередині, перш ніж оптимізатор запитів створить відсутні статистичні дані.

Щодо №1, мені здається, що SQL Server насправді робив би пошук по індексу, щоб визначити унікальність до того, як буде зроблено вставку / оновлення, і, отже, індекс не відображатиметься як не використовується.

Щодо №2, чи реально це можливо?

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

Ваші занепокоєння щодо DBA обидва.

Щодо №1, мені здається, що SQL Server насправді робив би пошук по індексу, щоб визначити унікальність до того, як буде зроблено вставку / оновлення, і, отже, індекс не відображатиметься як не використовується.

Гарантія унікальності може бути використана оптимізатором для вирішення того, які логічні перетворення або фізичні операції можна використовувати для отримання правильних результатів. Те, що оптимізатор покладається на гарантію унікальності для, наприклад, перетворення агрегації або вибору об'єднання з багатьма об'єднаннями, не відображатиметься в статистиці використання індексу, якщо тільки індекс не отримає фізичного доступу до остаточного плану виконання . Тому слід бути дуже обережним щодо видалення (або відключення) будь-якого унікального індексу або обмеження.

Щодо №2, чи реально це можливо?

Так, оптимізатор може використовувати статистику, пов’язану з індексом, без остаточного плану виконання, який містить будь-який доступ із використанням цього індексу. Процеси завантаження «цікавої» статистики, обчислення оцінок кардинальності та створення готового плану виконання є досить самостійними видами діяльності.

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

Ваш DBA знає його / її речі.

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