Как вычислить Num_Key_Cols для некластеризованного индекса с включенными в него столбцами?

Question

Я пытаюсь оценить размер индекса, используя информацию, предоставленную на MSDN website.

Рассмотрим таблицу «Таблица 1» с тремя столбцами в ней. Столбцы перечислены ниже,

1. Id Int, а не нулевой
2. Marks INT, а не нулевой
3. SubmitDate Дата, не нулевой

Изначально я создал кластерный первичный ключ Идентификатор, а затем планируется создать некластеризованный индекс с «Id» как «индексный столбец ключа» где as, «Знаки» и Столы «SubmitDate» будут использованы как «Включенные столбцы» в индекс.

Основываясь на вышеуказанном плане, я пытался оценить размер кластера без кластеризации до его создания. Пройдя через MSDN site, у меня есть много путаниц, которые нужно уточнить. Есть четыре шага, чтобы оценить некластерный размер ключа индекса и на первом этапе, 1,2 и 1,3 поясняются, как рассчитать Num_Key_Cols, Fixed_Key_Size, Num_Variable_Key_Cols и Max_Var_Key_Size. Но в 1,2 и 1.3 мы должны рассчитывать на основе типа ключа Index, у нас уже есть кластерный ключ индекса или нет, и мы включили столбцы или нет; это кажется запутанным. Может ли кто-нибудь помочь мне на основе информации, которую я представил о таблице примеров (Таблица 1), и структуре кластеров с некластеризованным индексом, которую я хотел бы создать.

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

Заранее спасибо.

Answer 1

Изначально я создал кластерный первичный ключ в столбце Id, а затем планируется создать некластеризованной индекс с «Id», как «индекс столбца ключа», где, как, «Marks» и «SubmitDate «столбцы будут использоваться как« Включенные столбцы »в индексе.

Я бы этого не сделал. Сделав Id как первичный ключ (т. Е. Уникальный), так и ключ кластеризации в таблице (всего 3 столбца), имеется небольшая точка, добавляющая дополнительный индекс NC на Id - кластерный индекс является достаточным.

Если у вас было большое количество столбцов (на странице) в таблице, тогда может возникнуть причина добавить еще один индекс NC на Id с включенными столбцами на (Marks, SubmitDate), поскольку плотность индекса NC будет выше. Но это явно не так.

Некоторые осветление MSDN NC проклейки ссылка:

• Direct индексировать столбцы необходимо учитывать на всех уровнях дерева.
• INCLUDE столбцы присутствуют только в листовых узлах дерева
• Num_Key_Cols = Num_Key_Cols + 1 только необходима, когда Sql Server добавляет 4 byte uniquifier, если ключ кластеризации не является уникальным. Вы сгруппированы по основному ключу, поэтому его уникальность, а не +1.

Не забудьте также сделать эмпирические измерения на реальных данных

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

В этом случае, я хотел бы предложить создать таблицу и заполнение его с приближенными данными, а затем измерить фактическое хранение данных с помощью инструментов, как sp_spaceused и sys.dm_db_index_physical_stats, например:

select * from sys.dm_db_index_physical_stats (DB_ID(), 
      OBJECT_ID(N'dbo.Table1'), NULL, NULL , 'DETAILED'); 

(размер страницы 8192)

Редактировать

Просто, чтобы показать, если у вас уже есть это место:

CREATE TABLE Table1 
(
    Id INT IDENTITY(1,1), 
    Marks INT NOT NULL, 
    SubmitDate DATE NOT NULL 
); 

ALTER TABLE Table1 ADD CONSTRAINT PK_Table1 PRIMARY KEY CLUSTERED (Id); 

Тогда нет смысла делать это, а также:

CREATE NONCLUSTERED INDEX IX_Table1 on Table1(Id) INCLUDE (Marks, SubmitDate) 

Поскольку индекс кластерным будет уже искать/сканирования на ID как performantly как индекс NC - вы просто удвоить потребность в памяти.

В качестве примечания также обратите внимание, что в целом это the clustered index key is included in all non-clustered indexes автоматически и не нужно явно добавлять в индексы без кластеризации.

Answer 2

SELECT 
OBJECT_NAME(i.OBJECT_ID) AS TableName, 
i.name AS IndexName, 
i.index_id AS IndexID, 
8 * SUM(a.used_pages) AS 'Indexsize(KB)' 
FROM sys.indexes AS i 
JOIN sys.partitions AS p ON p.OBJECT_ID = i.OBJECT_ID AND p.index_id = i.index_id 
JOIN sys.allocation_units AS a ON a.container_id = p.partition_id 
GROUP BY i.OBJECT_ID,i.index_id,i.name 
ORDER BY OBJECT_NAME(i.OBJECT_ID),i.index_id