DMV, чтобы найти недостающие индексы

Question

Я обнаружил, что следующий SQL предназначен для определения отсутствующих индексов.Я хотел бы лучше понять вывод.

   SELECT   migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) AS ExpectedImprovement
           , DB_NAME(mid.database_id)            AS DBName
           , mid.[object_id]                     AS ObjectID
           , mid.statement                       AS FullyQualifiedObjectName
           , ISNULL (mid.equality_columns,'') +
             CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN
                ','
             ELSE
                ''
             END +
             ISNULL (mid.inequality_columns, '') AS IndexColumns
           , ISNULL (mid.included_columns, '') AS IncludeColumns
           , migs.user_seeks
           , migs.user_scans
           , migs.last_user_seek
           , migs.last_user_scan
      FROM sys.dm_db_missing_index_groups      mig
INNER JOIN sys.dm_db_missing_index_group_stats migs ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details     mid  ON mig.index_handle = mid.index_handle
     WHERE migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) > 10
  ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC

Один из возвращаемых столбцов - «Включить столбцы».

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

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

Answer 1

Некластеризованный индекс содержит как список индексируемых столбцов, так и список столбцов, которые «включены» для быстрой ссылки.

Например, допустим, у вас есть таблица с 100 столбцами, но вы почти исключительно запрашиваете 5 из них, основываясь на дате.например,

select col1, col2, col3, col4, YourDate from YourTable where YourDate = '???'

Если вы проиндексировали только столбец даты, вам придется выполнить так называемый поиск RowID (или поиск по закладкам).Вы эффективно найдете нужный набор строк, но вам нужно будет вернуться к физической таблице, чтобы получить остальные 4 столбца (col1-col4), которые вы хотите выбрать.

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

create nonclustered index ix_YourTable on YourTable (
     YourDate)
include (
     col1, col2, col3, col4)

Теперь вы не возвращаетесь к таблице, чтобы получить столбец col1-4, вы читаете их непосредственно из индекса.Очевидно, это увеличивает объем памяти, необходимый для этого индекса.

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

select col1, col2, col3, col4, col5, YourDate from YourTable where YourDate = '???'

Вы по-прежнему будете использовать индекс, но выЯ буду выполнять поиск RID, чтобы получить данные для col5.Вам нужно добавить col5 в список включения вашего индекса, чтобы эффективно на него ссылаться.

Надеюсь, это поможет!

Answer 2

SQLServers позволяет вам «включать» неключевые столбцы (подробности здесь ).Основное различие между ключевыми столбцами и неключевыми столбцами в индексе заключается в том, что неключевые столбцы хранятся только на уровне листа индекса, в отличие от ключевых столбцов, которые хранятся на всех уровнях.

Я бы не советовал буквально следовать советам по выводу вашего скрипта (ваш скрипт хорош, не поймите меня неправильно), то есть вам не нужно создавать все предлагаемые индексы и включать всеколонны это хочет от вас.Исходя из моего опыта, SQLServer хочет, чтобы все ваши запросы имели индекс покрытия, который может повлиять на производительность обновления / вставки и увеличить размер базы данных.