Оптимизация индексов SQL Server

Question

У меня есть таблица с несколькими не связанными с PK индексами. К сожалению, есть некоторая двойственность в том, что несколько индексов ссылаются на один и тот же столбец с одинаковым порядком сортировки. Обычно я создаю покрывающие индексы, которые представляют агрегаты не связанных с PK индексов для моих таблиц, поскольку до тех пор, пока столбец индексируется, он будет использовать его при необходимости во время запросов. У меня простой вопрос: индексирует ли один и тот же столбец в нескольких индексах в одном и том же порядке сортировки ненужные ресурсы или SQL Server знает, что столбец уже проиндексирован и является просто перекрестной ссылкой для целей оптимизации?

ОБНОВЛЕНИЕ: В будущем следует спросить, улучшит ли действие ORDER BY наличие дублирующих индексов с небольшими изменениями. Например, если бы я упорядочил по A, B DESC, D бы специальный индекс с этим порядком фактически увеличил производительность по сравнению с одним индексом покрытия, который включает эти столбцы с одинаковым порядком сортировки. У меня сложилось впечатление, что ORDER BY будет полагаться только на индексы и не нуждается в специальных индексах для обеспечения производительности.

Answer 1

Каждый индекс будет отдельным - нет перекрестных ссылок и так далее.Так что да, если эти индексы являются дубликатами, вы можете потерять время.Но: вполне разумно включать один столбец в несколько индексов - например, составные индексы (несколько полей) и т. Д. Может иметь смысл присутствовать рядом.

SQL Server с 2005 года имеетдействительно хорошая функция под названием DMV (Dynamic Management View), которая позволяет проверять, не используются ли индексы

• вообще
• отсутствующие индексы, которые могут ускорить загрузку вашего запроса

Поиск отсутствующих индексов:

SELECT  
    object_name(object_id), d.*, s.*
FROM
    sys.dm_db_missing_index_details d 
INNER JOIN 
    sys.dm_db_missing_index_groups g ON d.index_handle = g.index_handle
INNER JOIN 
    sys.dm_db_missing_index_group_stats s ON    g.index_group_handle = s.group_handle
WHERE   
    database_id = db_id()
ORDER BY  
    object_id

Поиск неиспользуемых индексов:

DECLARE  @dbid INT

SELECT @dbid = DB_ID(DB_NAME())

SELECT   
    OBJECTNAME = OBJECT_NAME(I.OBJECT_ID),
    INDEXNAME = I.NAME,
    I.INDEX_ID
FROM     
    SYS.INDEXES I
JOIN 
    SYS.OBJECTS O ON I.OBJECT_ID = O.OBJECT_ID
WHERE    
    OBJECTPROPERTY(O.OBJECT_ID, 'IsUserTable') = 1
    AND I.INDEX_ID NOT IN (SELECT S.INDEX_ID
                            FROM SYS.DM_DB_INDEX_USAGE_STATS S
                            WHERE S.OBJECT_ID = I.OBJECT_ID
                                    AND I.INDEX_ID = S.INDEX_ID
                                    AND DATABASE_ID = @dbid)
ORDER BY 
    OBJECTNAME, I.INDEX_ID, INDEXNAME ASC

Answer 2

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

Answer 3

Количество используемых индексов - выбор между производительностью, выбранной против вставки / обновления / удаления. Дисковое пространство менее значимо.

Я много раз встречал индексы для таблицы t (A, B, C), такие как «A», «A, B», «A, B, C». Конечно, это не полезно. Некоторым инструментам нравится создавать такие индексы. Также не очень хорошая идея создавать ключи для ВСЕХ возможных запросов.

Answer 4

Мне не ясно, о чем вы спрашиваете.

Рассмотрим индекс для таблицы со столбцами A, B, C и D. У вас есть индексы для (A, B) и (B, A), все отсортированы по возрастанию. В этом случае, да, это создаст два индекса, но дополнительный индекс не будет потрачен впустую, потому что дополнительные столбцы в индексе помогают только с точки зрения поиска, когда есть дубликаты строк для всех предыдущих столбцов в индексе.

С другой стороны, индекс (A, B) с дополнительной «покрывающей колонкой» C и другой индекс (A, B) с дополнительной «покрывающей» колонкой D будет пустым пространством. Вы должны просто использовать (A, B) + C, D.

Answer 5

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