Indici columnstore - Linee guida per la progettazione

Si applica a:SQL ServerDatabase SQL di AzureIstanza gestita di SQL di AzureAzure Synapse AnalyticsAnalytics Platform System (PDW)Database SQL in Microsoft Fabric

Suggerimenti generali per la progettazione di indici columnstore. Bastano poche scelte oculate per ottenere gli alti livelli di compressione dei dati e di prestazioni delle query per cui sono progettati gli indici columnstore.

Prerequisiti

In questo articolo si presuppone una certa familiarità con la terminologia e l'architettura degli indici columnstore. Per altre informazioni, vedere Indici columnstore: Panoramica e Architettura degli indici columnstore.

Conoscere i requisiti per i dati

Prima di progettare un indice columnstore, è importante conoscere i requisiti per i dati nel modo più approfondito possibile. Ad esempio, valutare le risposte a queste domande:

• Quanto è grande il tavolo?
• Le mie query svolgono principalmente analisi che esaminano grandi intervalli di valori? La progettazione degli indici columnstore li rende efficaci per analisi di intervalli di grandi dimensioni, piuttosto che per la ricerca di valori specifici.
• Il mio carico di lavoro esegue molti aggiornamenti ed eliminazioni? Gli indici columnstore sono utili quando i dati sono stabili. Le interrogazioni dovrebbero aggiornare ed eliminare meno del 10% delle righe.
• Sono disponibili tabelle dei fatti e delle dimensioni per un data warehouse?
• È necessario eseguire analisi su un carico di lavoro transazionale? In tal caso, consultare le linee guida per la progettazione dei columnstore per l'analisi operativa in tempo reale.

Non è detto che sia necessario un indice columnstore. Le tabelle rowstore (o ad albero B) con heap o con indici clusterizzati offrono prestazioni ottimali con le query che cercano un valore specifico o che operano su un piccolo intervallo di valori. Usare gli indici rowstore con carichi di lavoro transazionali, poiché questi tendono a richiedere principalmente ricerche nelle tabelle invece di scansioni di ampi intervalli delle tabelle.

Scegli l'indice columnstore più adatto alle tue esigenze

Un indice columnstore può essere cluster o non cluster. Un indice columnstore raggruppato può avere uno o più indici B-tree non clusterizzati. Gli indici columnstore sono facili da provare. Se si crea una tabella come indice columnstore, è possibile riconvertire facilmente la tabella in tabella rowstore eliminando l'indice columnstore.

Di seguito è riportato un riepilogo delle opzioni e dei suggerimenti.

Opzione columnstore	Uso consigliato	Compressione
Indice columnstore raggruppato	Usare per: 1) Carico di lavoro di data warehouse tradizionale con modello a stella o a fiocco di neve 2) Carichi di lavoro Internet delle cose (IOT) per l'inserimento di grandi volumi di dati con aggiornamenti ed eliminazioni minimi.	in media 10x
indice columnstore ordinato	Usare quando viene eseguita una query su un indice columnstore clusterizzato tramite una singola colonna predicato ordinato o un set di colonne. Queste indicazioni sono simili alla scelta delle colonne chiave per un indice cluster rowstore, anche se i rowgroup sottostanti compressi si comportano in modo diverso. Per altre informazioni, vedere CREATE COLUMNSTORE INDEX e Ottimizzazione delle prestazioni con indici columnstore ordinati.	Media di 10 volte
Indici B-tree non clusterizzati su un indice columnstore cluster	Utilizzare per: 1. Applicare vincoli di chiave primaria e di chiave esterna su un indice columnstore clusterizzato. 2. Velocizzare le query che eseguono la ricerca di valori specifici o in intervalli di valori limitati. 3. Velocizzare gli aggiornamenti e le eliminazioni di righe specifiche.	10x in media, con ulteriore spazio di archiviazione per gli indici non cluster.
Indice columnstore non clusterizzato su un heap o indice B-tree basato su disco	Da utilizzare per: 1) Un carico di lavoro OLTP con alcune query analitiche. È possibile eliminare gli indici B-tree creati per l'analisi e sostituirli con un solo indice di archiviazione a colonne non clusterizzato. 2) Molti carichi di lavoro OLTP tradizionali che eseguono operazioni di estrazione, trasformazione e caricamento (ETL) per spostare i dati in un data warehouse separato. È possibile evitare le operazioni ETL e la necessità di un data warehouse separato creando un indice columnstore non cluster su alcune delle tabelle OLTP.	NCCI è un indice aggiuntivo che richiede in media il 10% in più di memoria di archiviazione.
Indice columnstore su una tabella in memoria	Le stesse indicazioni valide per un indice columnstore non-clustered su una tabella basata su disco, tranne che la tabella di base è una tabella in memoria.	L'indice columnstore è un indice aggiuntivo.

Usare un indice columnstore clusterizzato per tabelle di data warehouse di grandi dimensioni

L'indice cluster columnstore non è semplicemente un indice, ma è l'archiviazione principale della tabella. Permette di ottenere alti livelli di compressione dei dati e un notevole miglioramento delle prestazioni delle interrogazioni per le grandi tabelle di fatti e dimensioni di data warehouse. Gli indici columnstore cluster sono più adatti a query di analisi piuttosto che a query transazionali, perché le query di analisi eseguono tendenzialmente operazioni su grandi intervalli di valori piuttosto che ricerche di valori specifici.

Valutare la possibilità di usare un indice columnstore con cluster nei casi seguenti:

• Ogni partizione ha almeno un milione di righe. Gli indici columnstore usano rowgroup all'interno di ogni partizione. Se la tabella è troppo piccola per riempire un rowgroup all'interno di ogni partizione, è possibile che non si ottengano i vantaggi della compressione columnstore e delle prestazioni delle query.
• Le query eseguono principalmente operazioni di analisi su intervalli di valori. Ad esempio, per trovare il valore medio di una colonna, la query deve analizzare tutti i valori della colonna e poi aggregare i valori sommandoli per determinare il valore medio.
• La maggior parte degli inserimenti viene eseguita su grandi volumi di dati con aggiornamenti ed eliminazioni minimi. Molti carichi di lavoro, come i carichi Internet delle cose (IOT), eseguono l'inserimento di grandi volumi di dati con aggiornamenti ed eliminazioni minimi. Questi carichi di lavoro possono trarre vantaggio dai miglioramenti a livello di compressione e prestazioni delle query derivanti dall'uso di un indice columnstore cluster.

Non usare un indice cluster columnstore nei casi seguenti:

• La tabella richiede tipi di dati varchar(max), nvarchar(max) o varbinary(max). In alternativa, progettare l'indice columnstore in modo che non includa queste colonne (si applica a: SQL Server 2016 (13.x) e versioni precedenti).
• I dati della tabella non sono permanenti. Prendere in considerazione l'uso di un heap o una tabella temporanea quando è necessario archiviare ed eliminare i dati rapidamente.
• La tabella contiene meno di un milione di righe per partizione.
• Più del 10% delle operazioni sulla tabella sono aggiornamenti ed eliminazioni. Un numero elevato di aggiornamenti ed eliminazioni è causa di frammentazione. La frammentazione influisce sui tassi di compressione e sulle prestazioni delle query fino a quando non si esegue un'operazione denominata riorganizza, che forza tutti i dati nel columnstore e rimuove la frammentazione. Per altre informazioni, vedere Riduzione al minimo della frammentazione dell'indice negli indici columnstore.

Per ulteriori informazioni, vedere Indici columnstore nell'archiviazione dati.

Usare un indice columnstore ordinato per tabelle di data warehouse di grandi dimensioni

Per la disponibilità degli indici Columnstore ordinati, vedere indici Columnstore: Panoramica.

Prendere in considerazione l'uso di un indice columnstore ordinato negli scenari seguenti:

• Quando i dati sono relativamente statici (senza scritture ed eliminazioni frequenti) e la chiave di indice columnstore ordinata è statica, gli indici columnstore ordinati possono offrire vantaggi significativi in termini di prestazioni rispetto agli indici columnstore non ordinati o agli indici rowstore per i carichi di lavoro analitici.
• Più valori distinti ci sono nella prima colonna della chiave dell'indice columnstore ordinato, maggiori potrebbero essere i guadagni in termini di prestazioni. Ciò è dovuto all'eliminazione del segmento migliorata per i dati di tipo stringa. Per altre informazioni, consultare Eliminazione di segmenti.
• Scegliere una chiave di indice columnstore ordinata su cui viene spesso eseguita una query e che può trarre vantaggio dall'eliminazione dei segmenti, in particolare dalla prima colonna della chiave. I miglioramenti delle prestazioni dovuti all'eliminazione dei segmenti in altre colonne della tabella sono meno prevedibili.
• I casi d'uso in cui è necessario eseguire query solo sui dati analitici più recenti, ad esempio gli ultimi 15 secondi, gli indici columnstore ordinati possono fornire l'eliminazione dei segmenti per i dati meno recenti. La prima colonna nella chiave dei dati columnstore ordinati deve essere costituita dai dati di data/ora, ad esempio una data/ora inserita o creata. L'eliminazione dei segmenti sarebbe più efficace in un indice columnstore ordinato rispetto a un indice columnstore non ordinato.
• Prendere in considerazione gli indici columnstore ordinati nelle tabelle contenenti chiavi con dati GUID, in cui il tipo di dati uniqueidentifier può ora essere usato per l'eliminazione di segmenti .

Un indice columnstore ordinato potrebbe non essere efficace in questi scenari:

• Analogamente ad altri indici columnstore, una frequenza elevata di operazioni di inserimento potrebbe creare un numero eccessivo di operazioni di I/O di archiviazione.
• Per i carichi di lavoro in cui sono presenti molte operazioni di scrittura, la qualità dell'eliminazione dei segmenti verrà ridotta nel tempo a causa della manutenzione del rowgroup tramite lo spostamento delle tuple. Ciò può essere attenuato da una regolare manutenzione dell'indice columnstore con ALTER INDEX REORGANIZE.

Aggiungere indici albero B non clusterizzati per ricerche di tabelle efficienti

A partire da SQL Server 2016 (13.x), è possibile creare indici B-tree non cluster o indici rowstore come indici secondari su un indice columnstore cluster. L'indice B-tree non cluster viene aggiornato man mano che si verificano modifiche all'indice columnstore. Si tratta di una funzionalità potente con numerosi vantaggi.

L'uso di un indice albero B secondario consente di eseguire ricerche di righe specifiche in modo efficiente, senza dover analizzare tutte le righe. Sono disponibili anche altre opzioni. Ad esempio, è possibile applicare un vincolo di chiave primaria o chiave esterna utilizzando un vincolo UNIQUE su un indice B-tree. Poiché non è possibile inserire un valore non univoco nell'indice albero B, SQL Server non può inserire il valore nel columnstore.

Considera di utilizzare un indice B-tree su un indice columnstore per:

• Esegui query che cercano particolari valori o piccoli intervalli di valori.
• Imporre un vincolo, come un vincolo di chiave primaria o di chiave esterna.
• Per eseguire con efficienza operazioni di aggiornamento ed eliminazione. L'indice albero B consente di trovare rapidamente le righe specifiche per gli aggiornamenti e le eliminazioni, senza analizzare l'intera tabella o un'intera partizione di una tabella.
• È disponibile spazio aggiuntivo per l'archiviazione dell'indice albero B.

Usare un indice columnstore non clusterizzato per analisi in tempo reale

A partire da SQL Server 2016 (13.x), è possibile creare un indice columnstore non cluster su una tabella rowstore basata su disco o su una tabella OLTP in memoria. Questo rende possibile l'esecuzione di analisi in tempo reale su una tabella transazionale. Mentre le transazioni avvengono sulla tabella sottostante, è possibile eseguire analisi sull'indice columnstore. Dato che una sola tabella gestisce entrambi gli indici, le modifiche sono disponibili in tempo reale sia per l'indice rowstore che per l'indice columnstore.

Un indice columnstore consente di ottenere livelli di compressione dei dati 10 volte migliori rispetto a un indice rowstore, quindi richiede solo una piccola quantità di spazio di archiviazione aggiuntivo. Ad esempio, se la tabella rowstore compressa richiede 20 GB, l'indice columnstore potrebbe richiedere altri 2 GB. Lo spazio aggiuntivo necessario dipende anche dal numero di colonne nell'indice columnstore non cluster.

Valutare la possibilità di usare un indice columnstore non cluster nei casi seguenti:

• Esegui analisi in tempo reale su una tabella rowstore transazionale. È possibile sostituire gli indici B-tree esistenti progettati per l'analisi con un indice columnstore non clustered.

• Per evitare la necessità di un data warehouse separato. In genere, le aziende eseguono le transazioni in una tabella rowstore e quindi caricano i dati in un data warehouse separato per le operazioni di analisi. Per molti carichi di lavoro, è possibile eliminare il processo di caricamento e un data warehouse distinto creando un indice columnstore non clusterizzato sulle tabelle transazionali.

SQL Server 2016 (13.x) offre diverse strategie per rendere efficiente questo scenario. È facile provarlo perché è possibile abilitare un indice columnstore non cluster senza modifiche all'applicazione OLTP.

Per aggiungere ulteriori risorse di elaborazione, è possibile eseguire le operazioni di analisi su una replica secondaria leggibile. L'uso di una replica secondaria leggibile consente di separare l'elaborazione del carico di lavoro transazionale e del carico di lavoro di analisi.

Per altre informazioni, vedere Introduzione a Columnstore per l'analisi operativa in tempo reale

Per altre informazioni sulla scelta dell'indice columnstore ottimale, vedere il blog di Sunil Agarwal Which columnstore index is right for my workload? (Qual è l'indice columnstore più appropriato per un carico di lavoro?).

Usare le partizioni di tabella per la gestione dei dati e le prestazioni delle query

Gli indici columnstore supportano il partizionamento, che rappresenta una soluzione efficace per la gestione e l'archiviazione dei dati. Il partizionamento consente anche di migliorare le prestazioni delle query, limitando le operazioni a una o più partizioni.

Usare le partizioni per semplificare la gestione dei dati

Per le tabelle di grandi dimensioni, l'uso delle partizioni è l'unico modo pratico per gestire gli intervalli di dati. I vantaggi delle partizioni per le tabelle rowstore si applicano anche agli indici columnstore.

Ad esempio, sia le tabelle rowstore che le tabelle columnstore usano le partizioni per:

• Controllare le dimensioni dei backup incrementali. È possibile eseguire il backup delle partizioni in filegroup separati e quindi contrassegnarli come di sola lettura. In questo modo, i backup futuri ignorano i filegroup di sola lettura.
• Ridurre i costi di archiviazione spostando una partizione meno recente in uno spazio di archiviazione meno costoso. Ad esempio, è possibile usare il cambio della partizione per spostare una partizione in una posizione di archiviazione meno costosa.
• Eseguire operazioni in modo efficiente limitando le operazioni a una partizione. Ad esempio, è possibile selezionare solo le partizioni frammentate per la manutenzione degli indici.

Con un indice columnstore è inoltre possibile usare il partizionamento per:

• Risparmiare un ulteriore 30% sui costi di archiviazione. È possibile comprimere le partizioni meno recenti con le opzioni di COLUMNSTORE_ARCHIVE compressione. Le prestazioni delle query potrebbero risultare più lente, che potrebbero essere accettabili se la partizione viene eseguita raramente.

Usare le partizioni per migliorare le prestazioni delle query

L'uso delle partizioni consente di limitare le query all'analisi di partizioni specifiche, con conseguente contenimento del numero di righe da analizzare. Ad esempio, se l'indice viene partizionato in base agli anni e la query deve analizzare i dati dell'anno precedente, l'analisi sarà limitata a una sola partizione.

Usare meno partizioni per un indice columnstore

A meno che le dimensioni dei dati non siano sufficientemente grandi, un indice columnstore offre prestazioni migliori con meno partizioni, rispetto al numero di partizioni generalmente usato per un indice rowstore. Se non si dispone di almeno un milione di righe per partizione, la maggior parte delle righe potrebbe finire nel deltastore, dove non beneficiano del miglioramento delle prestazioni dato dalla compressione columnstore. Ad esempio, se si caricano un milione di righe in una tabella con 10 partizioni e ogni partizione riceve 100.000 righe, tutte le righe vanno ai rowgroup delta.

Esempio:

• Caricare 1.000.000 righe in una singola partizione o in una tabella non partizionata. È possibile ottenere un rowgroup compresso con 1.000.000 di righe. Questa è ideale per un'elevata compressione dei dati e ottime prestazioni delle query.
• Caricare 1.000.000 righe in modo uniforme in 10 partizioni. Ogni partizione riceve 100.000 righe, ovvero un numero minore rispetto alla soglia minima per la compressione del columnstore. Di conseguenza, l'indice columnstore potrebbe avere 10 gruppi di righe differenziali con 100.000 righe ciascuno. Esistono modi per forzare i gruppi di righe delta nel columnstore. Tuttavia, se si tratta delle uniche righe nell'indice columnstore, i gruppi di righe compressi sono troppo piccoli per ottenere una compressione ottimale e migliori prestazioni delle query.

Per altre informazioni sul partizionamento, vedere il post di blog di Sunil Agarwal Should I partition my columnstore index? (È consigliabile partizionare l'indice columnstore?).

Scegliere il metodo di compressione dei dati appropriato

L'indice columnstore offre due opzioni per la compressione dei dati: compressione del columnstore e compressione dell'archivio. È possibile scegliere l'opzione di compressione quando si crea l'indice o modificarlo in un secondo momento con ALTER INDEX ... REBUILD.

Usare la compressione del columnstore per ottimizzare le prestazioni di query

La compressione del columnstore consente in genere di ottenere tassi di compressione 10 volte migliori rispetto agli indici rowstore. Si tratta del metodo di compressione standard per gli indici columnstore e consente di ottenere prestazioni migliori per le query.

Usare la compressione degli archivi per ottenere livelli ottimali di compressione dei dati

La compressione degli archivi è progettata per ottenere la massima compressione quando le prestazioni delle query non sono così importanti e consente di ottenere tassi di compressione dei dati migliori rispetto alla compressione del columnstore, anche se questo vantaggio ha un prezzo. La compressione e la decompressione dei dati richiedono infatti più tempo, quindi non è una soluzione adatta se sono necessarie prestazioni veloci per le query.

Usare le ottimizzazioni per convertire una tabella rowstore in un indice columnstore

Se i dati sono già disponibili in una tabella rowstore, è possibile usare l'istruzione CREATE COLUMNSTORE INDEX per convertire la tabella in un indice columnstore cluster. Le due ottimizzazioni descritte di seguito migliorano le prestazioni delle query dopo la conversione della tabella.

Usare MAXDOP per migliorare la qualità del rowgroup

È possibile configurare il numero massimo di processori per la conversione di un indice heap o un indice B-tree cluster in un indice columnstore. Per configurare i processori, usare l'opzione per il massimo grado di parallelismo (MAXDOP).

Se si dispone di grandi quantità di dati, MAXDOP 1 potrebbe essere troppo lento. È possibile ottenere buoni risultati aumentando MAXDOP a 4. Se questo porta a qualche rowgroup che non ha il numero ottimale di righe, è possibile eseguire ALTER INDEX REORGANIZE per unirli insieme in background.

Mantenere l'ordinamento di un indice B-tree

Dato che le righe vengono già archiviate con un ordinamento nell'indice albero B, il fatto di mantenere tale ordinamento quando le righe vengono compresse nell'indice columnstore può portare a un miglioramento delle prestazioni delle query.

L'indice columnstore non ordina i dati, ma usa i metadati per tenere traccia dei valori minimi e massimi di ogni segmento di colonna in ogni rowgroup. Durante l'analisi di un intervallo di valori, può rapidamente calcolare quando ignorare il rowgroup. Quando i dati sono ordinati, possono essere ignorati più gruppi di righe.

Per mantenere l'ordinamento durante la conversione:

• Usare CREATE COLUMNSTORE INDEX con la clausola DROP_EXISTING. Viene così mantenuto anche il nome dell'indice. Se si dispone di script che usano già il nome dell'indice rowstore, non è necessario aggiornarli.

  Questo esempio converte un indice rowstore clusterizzato su una tabella denominata MyFactTable in un indice columnstore clusterizzato. Il nome dell'indice, ClusteredIndex_d473567f7ea04d7aafcac5364c241e09, rimane invariato.

  SQL

  CREATE CLUSTERED COLUMNSTORE INDEX ClusteredIndex_d473567f7ea04d7aafcac5364c241e09
  ON MyFactTable
  WITH (DROP_EXISTING = ON);
  

Comprendere l'eliminazione dei segmenti

Ogni rowgroup contiene un segmento di colonna per ogni colonna della tabella. Ogni segmento di colonna è compresso e archiviato su un supporto fisico.

Esistono metadati con ogni segmento che consentono l'eliminazione rapida dei segmenti senza leggerli. Le scelte del tipo di dati possono avere un impatto significativo sulle prestazioni delle query sull'indice columnstore, basate su predicati di filtro comuni. Per altre informazioni, consultare Eliminazione di segmenti.

Attività correlate

La tabella seguente riepiloga le attività per la creazione e la manutenzione degli indici columnstore.

Attività	Articoli di riferimento	Note
Creare una tabella come columnstore.	CREATE TABLE (Transact-SQL)	A partire da SQL Server 2016 (13.x), è possibile creare la tabella come indice columnstore cluster. Non è necessario creare prima una tabella rowstore e quindi convertirla in columnstore.
Creare una tabella in-memory con un indice columnstore.	CREATE TABLE (Transact-SQL)	A partire da SQL Server 2016 (13.x), è possibile creare una tabella ottimizzata per la memoria con un indice columnstore. L'indice columnstore può anche essere aggiunto dopo aver creato la tabella, usando la sintassi ALTER TABLE ADD INDEX.
Convertire una tabella rowstore in un columnstore.	CREATE COLUMNSTORE INDEX (Transact-SQL)	Convertire un heap o un albero B esistente in un columnstore. Gli esempi illustrano come gestire gli indici esistenti e il nome dell'indice quando si esegue questa conversione.
Convertire una tabella columnstore in un rowstore.	CREATE CLUSTERED INDEX (Transact-SQL) oppure Convertire una tabella columnstore di nuovo in un heap rowstore	Di solito non è necessario eseguire questa conversione, ma talvolta potrebbe presentarsene la necessità. Gli esempi illustrano come convertire un columnstore in un heap o un indice clusterizzato.
Creare un indice columnstore per una tabella rowstore.	CREATE COLUMNSTORE INDEX (Transact-SQL)	Una tabella rowstore può avere un solo indice columnstore. A partire da SQL Server 2016 (13.x), l'indice columnstore può avere una condizione di filtro. Gli esempi illustrano la sintassi di base.
Creare indici ad alte prestazioni per l'analisi operativa.	Introduzione a columnstore per l'analisi operativa in tempo reale	Descrive come creare indici columnstore e indici albero B complementari in modo che le query OLTP usino gli indici albero B e le query di analisi usino gli indici columnstore.
Creare indici columnstore efficienti per il data warehousing.	Indici columnstore nell'ambito del data warehousing	Descrive come usare gli indici B-tree con le tabelle columnstore per creare query di data warehousing performanti.
Usare un indice B-tree per imporre un vincolo di chiave primaria su un indice columnstore.	Indici columnstore nell'archiviazione dati	Illustra come combinare indici B-tree e indici columnstore per imporre vincoli di chiave primaria sull'indice columnstore.
Rimuovere un indice columnstore	DROP INDEX (Transact-SQL)	Per rimuovere un indice columnstore si usa la sintassi standard DROP INDEX utilizzata dagli indici B-tree. La rimozione di un indice columnstore raggruppato converte la tabella columnstore in un heap.
Eliminare una riga da un indice di archiviazione a colonne	DELETE (Transact-SQL)	Usare DELETE (Transact-SQL) per eliminare una riga. Riga columnstore: SQL Server contrassegna la riga come eliminata logicamente ma recupera lo spazio di archiviazione fisico della riga solo dopo che l'indice è stato ricompilato. Riga deltastore: SQL Server elimina la riga logicamente e fisicamente.
Aggiornare una riga nell'indice columnstore	UPDATE (Transact-SQL)	Usare UPDATE (Transact-SQL) per aggiornare una riga. Riga columnstore: SQL Server contrassegna la riga come eliminata logicamente e quindi inserisce la riga aggiornata nel deltastore. Riga deltastore: SQL Server aggiorna la riga nel deltastore.
Forzare il passaggio di tutte le righe del deltastore nel columnstore.	ALTER INDEX (Transact-SQL) ... REBUILD Ottimizzare la manutenzione dell'indice per migliorare le prestazioni delle query e ridurre il consumo di risorse	ALTER INDEX con l'opzione REBUILD costringe tutte le righe ad entrare nel columnstore.
Deframmentare un indice columnstore	ALTER INDEX (Transact-SQL)	ALTER INDEX ... REORGANIZE consente di deframmentare indici columnstore online.
Unire tabelle con indici columnstore.	MERGE (Transact-SQL)

Contenuto correlato

Per creare un indice columnstore vuoto per:

• SQL Server o SQL Database, consultare CREATE TABLE (Transact-SQL).
• Per Azure Synapse Analytics, vedere CREATE TABLE (Azure Synapse Analytics).

Per ulteriori informazioni su come convertire un heap rowstore esistente o un indice B-tree in un indice columnstore clusterizzato, o su come creare un indice columnstore non clusterizzato, vedere CREATE COLUMNSTORE INDEX (Transact-SQL).

• Novità degli indici columnstore
• Indici columnstore nell'archiviazione dei dati
• Indici columnstore - Prestazioni delle query