Определение того, что индексы в таблице не используются

Я запускаю этот скрипт, чтобы попытаться найти посторонние индексы

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 / seeks ...? Потому что в одной таблице я обнаружил 5, которые не имели активности пользователя, а одна имела системную активность 10 дней назад. У кого-нибудь есть понимание того, что система может быть сканирует / ищет / ищет? Эти таблицы кажутся слишком переиндексированными, и я хотел бы урезать жир.

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

Если нет доступа пользователя, скопируйте их. Просто помните о временных рамках, в течение которых вы решаете, что они больше не используются. Например, есть ли еженедельные или ежемесячные отчеты?

Пока вы ищите, поищите дубликаты индексов .

Изменить: относительно ссылки SSC

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

Я привел пару систем обратно на грань, не делая ничего, кроме удаления неиспользуемых и дублированных индексов. Чрезмерная индексация может вызвать хаос.

Это ваша система, вы должны понимать и взвешивать риски, связанные с оставлением этих индексов на месте или их отбрасыванием. Если вы решите продолжить работу, запишите, что вы делаете, почему вы это делаете, составьте сценарии индексов и опубликуйте их для всех заинтересованных сторон.

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

Я не буду беспокоиться о системной активности. Это не то, что будет хуже, если вы удалите индексы, на самом деле это может быть действие, которое происходит только с этим индексом, потому что он существует. Главное, что вас волнует, это активность чтения и записи и балансирование.

Помните, что индексы также предоставляют полезную информацию оптимизатору запросов, даже если они не используются. Например, я сделал немало вещей, касающихся влияния уникальности. Если вы удалите уникальный индекс, так как у него нет поиска или сканирования, это все равно может отрицательно повлиять на производительность.

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