Функциональность некластеризованных индексов относительно поиска кластерного индекса

Question

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

Скажите, что у вас есть следующие таблицы:

/* 
TABLES: 
TABLE_A (PK_ID INT, [random columns], B_ID INT (INDEXED, and references TABLE_B.PK_ID)) 
TABLE_B (PK_ID INT, [random columns], C_ID INT (INDEXED, and references TABLE_C.PK_ID)) 
TABLE_C (PK_ID INT, [random columns]) 
*/ 

SELECT * 
FROM TABLE_A A 
JOIN TABLE_B B ON B.PK_ID = A.B_ID 
JOIN TABLE_C C ON C.PK_ID = B.C_ID 
WHERE A.randcolumn1 = 'asd' AND B.randcolumn2 <> 5 

Теперь, так как B присоединяется к А с кластерными колонками ПК, не следует, что означает, что не будет использоваться индекс B.C_ID , поскольку информация уже возвращена с помощью кластерного индекса B.PK_ID? На самом деле, разве неверно, что индекс на B.C_ID никогда не будет использоваться, если запрос не нацелен на значения идентификатора этого индекса?

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

Спасибо!

Answer 1

Оптимизатор запросов может делать все, что ему нравится. Он может выполнить второе соединение, сканируя таблицу C, и для каждой строки, просматривая соответствующую строку в B. Указанный вами индекс поможет с этим поиском.

SQL Server предоставляет статистику, чтобы сказать вам, если индекс фактически используется:

select db_name(ius.database_id) as Db 
,  object_name(ius.object_id) as [Table] 
,  max(ius.last_user_lookup) as LastLookup 
,  max(ius.last_user_scan) as LastScan 
,  max(ius.last_user_seek) as LastSeek 
,  max(ius.last_user_update) as LastUpdate 
from sys.dm_db_index_usage_stats as ius 
where ius.[database_id] = db_id() 
     and ius.[object_id] = object_id('YourTableName') 
group by 
     ius.database_id 
,  ius.object_id 

Если индекс не используется в течение более 2-х месяцев, то, как правило, безопасно бросить его.