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

Я запускав цей сценарій, щоб спробувати знайти сторонні індекси

select o.name as TableName, i.name as IndexName, p.reserved_page_count * 8.0 / 1024 as     SpaceInMB, s.*
from     sys.dm_db_index_usage_stats s
inner join sys.objects o on s.object_id = o.object_id
inner join sys.indexes i on i.index_id = s.index_id and i.object_id = o.object_id
inner join sys.dm_db_partition_stats p on i.index_id = p.index_id and o.object_id =      p.object_id
where o.name = ‘TableName’

Я знаю, що коли last_user_seek / scan / lookup абсолютно недійсні, що жоден користувач не використовував індекс з моменту останнього перезавантаження. Але мені цікаво, що таке system_scans / lookups / see…? Тому що в певній таблиці я знайшов 5, які не мали активності користувачів, але одна мала системну активність 10 днів тому. Хтось має уявлення про те, якою може бути система сканування / пошуку / пошуку? Ці таблиці здаються справді завищеними, і я хотів би обрізати жир.

Підтримка індексу (відновлення / реорганізація) та активність DBCC CHECKDB, швидше за все, можливо оновлення статистики. Налаштоване будь-яке планове обслуговування?

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

Поки ви шукаєте, викопайте також і для дублікатів індексів .

Редагувати: стосовно SSC-посилання

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

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

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

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

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

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

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