У меня такой вопрос: если некластеризованный индекс индексирует больше столбцов, чем используется запросом, означает ли это медленное выполнение запроса, чем индекс, который точно соответствует запросу?
Нет, наличие большего количества столбцов не замедляет время запроса для запросов, которые используют первые 1, 2, n столбцов в индексе.При этом, если вы ограничены в памяти, загрузка индекса в память может вытолкнуть другие вещи из памяти и замедлить запрос, но если у вас достаточно памяти, это не должно быть проблемой.
По мере увеличения числа отдельных запросов увеличивается и количество перестановок столбцов, используемых в их предложениях WHERE.Я не уверен относительно компромисса между наличием множества индексов с небольшим количеством столбцов (по одному на каждый запрос) и меньшим количеством индексов для большего количества столбцов.
Вы должны добавить наиболее часто запрашиваемые уникальные поляв индексы в первую очередь.Меньшее количество индексов с большим количеством столбцов может не дать вам того, что вы хотите.
Например, если у вас есть индекс со следующими столбцами:
- СтолбецA
- Столбец B
- ColumnC
- ColumnD
- ColumnE
- ColumnF
в таком порядке, запрашивает фильтрацию по ColumnA, ColumnB, ColumnC, ColumnD... будет использовать индекс, но если вы просто запрашиваете у ColumnE или ColumnF, он не будет использовать индекс.
Используйте другой подход, если у вас есть шесть индексов для одной таблицы с одним столбцом
- Index1 - столбец A
- Index2 - столбец B
- Index3 - столбец C
- Index4 - столбец D
- Index5 - столбец E
- Index6 - ColumnF
, в этом случае только один из этих 6 индексов будет использоваться для любого запроса.
Кроме того, если индекс содержит значение, которое не очень избирательно,тогда это может не помочь вам.Например, если у вас есть столбец с именем GENDER, который может содержать следующие значения (Мужской, Женский и Неизвестный), то, вероятно, он не поможет вам включить этот столбец в индекс.Когда запрос выполняется, SQL Server может определить, что столбец недостаточно селективен, и просто предположить, что полное сканирование таблицы будет быстрее.
Существует множество способов выяснить, какие индексы используются вашим запросом,но один из подходов, который я использую, - это посмотреть на индексы, которые никогда не используются.Запустите следующий запрос в своей базе данных и выясните, действительно ли используются используемые вами индексы.
SELECT iv.table_name,
i.name AS index_name,
iv.seeks + iv.scans + iv.lookups AS total_accesses,
iv.seeks,
iv.scans,
iv.lookups,
t.indextype,
t.indexsizemb
FROM (SELECT i.object_id,
Object_name(i.object_id) AS table_name,
i.index_id,
SUM(i.user_seeks) AS seeks,
SUM(i.user_scans) AS scans,
SUM(i.user_lookups) AS lookups
FROM sys.tables t
INNER JOIN sys.dm_db_index_usage_stats i
ON t.object_id = i.object_id
GROUP BY i.object_id,
i.index_id) AS iv
INNER JOIN sys.indexes i
ON iv.object_id = i.object_id
AND iv.index_id = i.index_id
INNER JOIN (SELECT sys_schemas.name AS schemaname,
sys_objects.name AS tablename,
sys_indexes.name AS indexname ,
sys_indexes.type_desc AS indextype ,
CAST(partition_stats.used_page_count * 8 / 1024.00 AS DECIMAL(10, 3)) AS indexsizemb
FROM sys.dm_db_partition_stats partition_stats
INNER JOIN sys.indexes sys_indexes
ON partition_stats.[object_id] = sys_indexes.[object_id]
AND partition_stats.index_id = sys_indexes.index_id
AND sys_indexes.type_desc <> 'HEAP'
INNER JOIN sys.objects sys_objects
ON sys_objects.[object_id] = partition_stats.[object_id]
INNER JOIN sys.schemas sys_schemas
ON sys_objects.[schema_id] = sys_schemas.[schema_id]
AND sys_schemas.name <> 'SYS') AS t
ON t.indexname = i.name
AND t.tablename = iv.table_name
--WHERE t.IndexSizeMB > 200
WHERE iv.seeks + iv.scans + iv.lookups = 0
ORDER BY total_accesses ASC;
Обычно я отслеживаю индексы, которые никогда не использовались или не использовались несколько раз.месяцев после перезагрузки SQL Server, и определите, следует ли их удалить или нет.Иногда слишком много индексов может замедлить работу SQL Server, чтобы определить оптимальный путь для выполнения запроса, а удаление неиспользуемых индексов может ускорить этот процесс.
Надеюсь, это поможет понять ваши индексы.