Каков эффект включения столбца "включить" в некластеризованный индекс, который уже является частью ключа кластеризации?

Question

Предположим, я разбил таблицу на (RetailerID, PurchaseDate, UserID). Это "ключ кластеризации", и ключи кластеризации всегда включены во все некластеризованные индексы. /questions/33290858/kak-neklasterizovannyij-indeks-mozhet-vyivodit-stolbets-kotoryij-ne-vklyuchen-v-indeks/33290861#33290861 /questions/14841715/razve-ploho-imet-neklasterizovannyij-indeks-soderzhaschij-pervichnyij-klyuch-iz-klasternogo-indeksa/14841740#14841740

Затем я создаю некластеризованный индекс "StorePurchasesIndex" с ключом (RetailerID, StoreID, PurchaseDate), чтобы сделать поиск, который включает только подмножество определенных магазинов быстрее.

Первый вопрос: нужно ли явно включать UserID как включенный столбец, или он будет там неявным образом благодаря ключу кластеризации, включая его? Я уверен, что мне не нужно включать UserID явно в этом случае, но поправьте меня, если я ошибаюсь.

Что мне действительно интересно знать, так это то, что произойдет, если я включу явно UserID как столбец включения. Будет ли он включен в индекс избыточно, один раз как часть ключа кластеризации, и снова как включенный столбец? Или SQL Server распознает намерение и избегает его двойного хранения, поскольку он уже включен в силу ключа кластеризации?

Второй вопрос: если он не включен избыточно, есть ли преимущество в том, чтобы включить его явно. Например, это обеспечит UserID включается в будущем, даже если ключ кластеризации изменяется таким образом, что исключает UserID а индекс перестраивается?

Answer 1

Для некластеризованного индекса ключ / ключи индекса по умолчанию присутствуют на уровне корня и листа.

Этот случай по умолчанию зависит от определения вашего некластеризованного индекса.

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

При создании уникального кластеризованного индекса SQL Server не будет включать кластеризованный ключ на корневом уровне, но будет включать на уровне листьев.

Так что подхожу к вашим вопросам..

Первый вопрос: нужно ли явно включать UserID в качестве включенного столбца или он будет там неявным образом благодаря ключу кластеризации, включающему его?

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

Что мне действительно интересно знать, так это то, что произойдет, если я действительно включу UserID в качестве столбца включения. Будет ли он включен в индекс избыточно, один раз как часть ключа кластеризации, и снова как включенный столбец? Или SQL Server распознает намерение и избегает его двойного хранения, поскольку он уже включен в силу ключа кластеризации?

SQL Server достаточно умен, чтобы игнорировать это..

Второй вопрос: если он не включен избыточно, есть ли преимущество в том, чтобы включить его явно.

Даже если вы добавите SQL Server будет игнорировать столбец

Например, будет ли он гарантировать, что UserID будет включен в будущем, даже если ключ кластеризации изменится таким образом, что он исключит UserID и индекс будет перестроен?

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