Archiviazione dell'indice non cluster sull'archivio colonne cluster

In SQL Server, un indice non cluster non univoco su una tabella di archivio righe incorpora il segnalibro dell'oggetto base (RID o chiave di clustering) a tutti i livelli della struttura dell'indice non cluster. Il segnalibro viene archiviato come parte della chiave di indice non cluster a tutti i livelli di indice.

D'altra parte, se l'indice non cluster è univoco , il segnalibro è presente solo a livello foglia dell'indice, non come parte della chiave (il segnalibro è presente come una o più colonne incluse, in effetti).

In SQL Server 2016 è possibile creare un indice b-tree non cluster su una tabella orientata alla colonna (una che ha un indice columnstore cluster).

1. Qual è il 'segnalibro' utilizzato per un indice b-tree non cluster su una tabella columnstore cluster?
2. Le differenze tra indici non cluster unici e non unici descritti sopra si applicano ancora?

1. Il "segnalibro" è il localizzatore originale dell'indice columnstore (per "Pro SQL Server Internals" di Dmitri Korotkevitch). Questo è un valore di 8 byte, con l'indice columnstore row_group_idnei primi 4 byte e un offset nei secondi 4 byte.

2. Se si utilizza DBCC PAGEper guardare l'indice non cluster, il localizzatore originale dell'indice columnstore a 8 byte appare nella colonna "uniquifier" DBCC PAGEdell'output. Ciò dimostra che un indice univoco non cluster non deve includere il localizzatore di righe columnstore, mentre un indice non cluster non univoco lo fa.

Il codice seguente crea una tabella organizzata da columnstore con un indice non cluster b-tree unico e non univoco sulla stessa colonna:

CREATE TABLE dbo.Heapish
(
    c1 bigint NOT NULL,
    c2 bigint NOT NULL,
    INDEX CCI_dbo_Heapish CLUSTERED COLUMNSTORE
);
GO
INSERT dbo.Heapish WITH (TABLOCKX)
    (c1, c2)
SELECT TOP (1024 * 1024 * 8)
    c1 = ROW_NUMBER() OVER
        (ORDER BY C1.[object_id], C1.column_id),
    c2 = ROW_NUMBER() OVER
        (ORDER BY C1.[object_id], C1.column_id)
FROM master.sys.columns AS C1
CROSS JOIN master.sys.columns AS C2
ORDER BY
    c1
OPTION (MAXDOP 1);
GO
CREATE UNIQUE NONCLUSTERED INDEX UNIQUE_c2 ON dbo.Heapish (c2) WITH (MAXDOP = 1);
CREATE NONCLUSTERED INDEX NONUNIQUE_c2 ON dbo.Heapish (c2) WITH (MAXDOP = 1);

Possiamo vedere la dimensione della riga dell'indice a diversi livelli dell'albero b usando sys.dm_db_index_physical_stats:

SELECT
    DDIPS.index_level,
    DDIPS.page_count,
    DDIPS.record_count,
    DDIPS.min_record_size_in_bytes,
    DDIPS.max_record_size_in_bytes
FROM sys.dm_db_index_physical_stats
(
    DB_ID(),
    OBJECT_ID(N'dbo.Heapish', N'U'),
    INDEXPROPERTY(OBJECT_ID(N'dbo.Heapish', N'U'), N'UNIQUE_c2', 'IndexID'),
    NULL, 'DETAILED'
) AS DDIPS;

SELECT
    DDIPS.index_level,
    DDIPS.page_count,
    DDIPS.record_count,
    DDIPS.min_record_size_in_bytes,
    DDIPS.max_record_size_in_bytes
FROM sys.dm_db_index_physical_stats
(
    DB_ID(),
    OBJECT_ID(N'dbo.Heapish', N'U'),
    INDEXPROPERTY(OBJECT_ID(N'dbo.Heapish', N'U'), N'NONUNIQUE_c2', 'IndexID'),
    NULL, 'DETAILED'
) AS DDIPS;

L'output è:

Entrambe le strutture hanno la stessa dimensione di riga a livello foglia, ma l'indice non cluster non unico è di 12 byte più grande dell'indice non cluster univoco a livello non foglia a causa del localizzatore di colonne a 8 byte, più 4 byte di overhead per la prima variabile -length colonna in una riga (l'unificatore è di lunghezza variabile).