Стандартные неиспользуемые индексы

[oip]

В большинстве случаев в коде индекс упомянут и не должен быть, а значит и перекрестными ссылками он не найдется. SQL Server сам решает, какой из индексов надо использовать.

Статистику использования индексов можно посмотреть во вьюшке sys.dm_db_index_usage_stats. Отсюда можно определить и выключить реально неиспользуемые индексы.
http://technet.microsoft.com/en-us/l.../ms188755.aspx

Еще есть полезная вьюшка sys.dm_db_index_operational_stats.
http://msdn.microsoft.com/en-us/library/ms174281.aspx

О различиях между ними тут: http://blogs.msdn.com/b/craigfr/arch...nal-stats.aspx

[Link]

Цитата:

Сообщение от oip

В большинстве случаев в коде индекс упомянут и не должен быть, а значит и перекрестными ссылками он не найдется. SQL Server сам решает, какой из индексов надо использовать.

Статистику использования индексов можно посмотреть во вьюшке sys.dm_db_index_usage_stats. Отсюда можно определить и выключить реально неиспользуемые индексы.
http://technet.microsoft.com/en-us/l.../ms188755.aspx

Еще есть полезная вьюшка sys.dm_db_index_operational_stats.
http://msdn.microsoft.com/en-us/library/ms174281.aspx

О различиях между ними тут: http://blogs.msdn.com/b/craigfr/arch...nal-stats.aspx

Спасибо за конструктив, понял куда копать!

[AlexeyS]

Этот запрос возвращает список индексов, которые никогда не использовались в планах исполнения запросов,
и показывает число изменений на страницах каждого такого индекса. Вы можете найти не только индексы,
которые лежат в базе данных мёртвым грузом, но и те индексы,
которые за счёт большого числа изменений приносят только вред
(в виде затрат на изменения значений ключей индекса).

SELECT   OBJECT_NAME(i.object_id) AS [Table Name],
         i.name AS [Not Used Index Name],
         s.last_user_update AS [Last Update Time],
         s.user_updates AS [Updates]
FROM     sys.dm_db_index_usage_stats AS s
JOIN     sys.indexes AS i
ON       i.object_id = s.object_id
AND      i.index_id = s.index_id
JOIN     sys.objects AS o
ON       o.object_id = s.object_id
WHERE    s.database_id = DB_ID()
AND      (    user_scans   = 0
          AND user_seeks   = 0
          AND user_lookups = 0
          AND last_user_scan   IS NULL
          AND last_user_seek   IS NULL
          AND last_user_lookup IS NULL 
         )
AND      OBJECTPROPERTY(i.[object_id],         'IsSystemTable'   ) = 0
AND      INDEXPROPERTY (i.[object_id], i.name, 'IsAutoStatistics') = 0
AND      INDEXPROPERTY (i.[object_id], i.name, 'IsHypothetical'  ) = 0
AND      INDEXPROPERTY (i.[object_id], i.name, 'IsStatistics'    ) = 0
AND      INDEXPROPERTY (i.[object_id], i.name, 'IsFulltextKey'   ) = 0
AND      (i.index_id between 2 AND 250 OR (i.index_id=1 AND OBJECTPROPERTY(i.[object_id],'IsView')=1))
AND      o.type <> 'IT'
--ORDER BY OBJECT_NAME(i.object_id) 
order by [Updates] desc

если будете удалять индексы - следите за TransactionLog-ом. Индекс удаляется в транзакции и лог может запросто вырасти в разы, если удалить сразу несколько больших индексов (это актуально только есть ограничения на размер лога).

[Link]

Цитата:

Сообщение от AlexeyS

Этот запрос возвращает список индексов, которые никогда не использовались в планах исполнения запросов,
и показывает число изменений на страницах каждого такого индекса. Вы можете найти не только индексы,
которые лежат в базе данных мёртвым грузом, но и те индексы,
которые за счёт большого числа изменений приносят только вред
(в виде затрат на изменения значений ключей индекса).

Спасибо, нашел похожий запрос здесь.

Цитата:

Сообщение от AlexeyS

если будете удалять индексы - следите за TransactionLog-ом. Индекс удаляется в транзакции и лог может запросто вырасти в разы, если удалить сразу несколько больших индексов (это актуально только есть ограничения на размер лога).

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

[Link]

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

Еще может кому будет полезно, в сиквеле (2008) уже есть встроенный отчеты по статистике индексов, то о чем выше писал уважаемый oip. Запустил, сохранил в эксель и можно анализировать. Очень удобно, особенно в сильно запущенных случаях. Так же в отчете (Service Dashboard) можно посмотреть дату перезапуска службы.

[Link]

Вот что пишут:

 When an Index Logical Scan Fragmentation exceeds 50%, SQL will ignore the Statistics recommendations and perform a Table Scan instead.

Получается, что нельзя полагаться на статистику по индексу, если фрагментация больше 50%?