Se un database ha solo un solo inserimento, è male indicizzare ogni possibile combinazione di colonne?

Sto lavorando a un sistema di reporting che richiederà grandi query di selezione, ma si basa su un database che viene riempito solo una volta. Il sistema di gestione del database è Microsoft SQL Server 2017. Probabilmente esiste un modo migliore per progettare un sistema come questo, ma affrontiamo questo in teoria.

Teoricamente parlando:

1. Se disponiamo di un database molto grande (oltre 150 milioni di righe su più tabelle)
2. E possiamo supporre che il database verrà popolato solo una volta.

L'indicizzazione di ogni possibile combinazione di colonne potrebbe avere un impatto negativo sulle prestazioni in una query selezionata?

Sì, influenzerà il tempo di compilazione del piano iniziale poiché l'ottimizzatore avrà molti percorsi di accesso extra ai dati da considerare.

Dato che sei su SQL Server 2017, caricando una volta ed eseguendo i rapporti, perché non utilizzare un indice di archivio di colonne in cluster?

Questa sembra essere la soluzione ideale per la tua necessità di indicizzare ogni possibile combinazione di colonne.

Indici Columnstore - Panoramica

Se in una tabella sono presenti N colonne, ogni possibile combinazione di colonne è 2 ^ N-1 (rimuovendo il set vuoto). Per 10 colonne che significherebbe 1023 indici, per 20 colonne finiamo con un enorme 1048575 indici. La maggior parte degli indici non verrà mai utilizzata ma dovrà essere presa in considerazione dall'ottimizzatore. È possibile che l'ottimizzatore scelga un indice non ottimale anziché uno migliore. Non prenderei il percorso di generare tutti i tipi di indici, invece di cercare di capire quali indici sarebbero effettivamente utili.

EDIT ha corretto il numero di possibili indici

Come sottolinea Jeff , è anche peggio di 2 ^ N (power-set) poiché (3,2,1) è chiaramente diverso da (1,2,3). Per N colonne possiamo scegliere la prima posizione in un indice che contiene tutte le colonne in N modi. Per la seconda posizione in N-1 modi, ecc. Quindi, finiamo con N! diversi indici di dimensioni intere. Nessuno di questi indici è incluso in un altro indice in questo set. Inoltre, non possiamo aggiungere un altro indice più breve in modo che non sia coperto da alcun indice completo. Il numero di indici è quindi N !. L'esempio per 10 colonne, quindi, diventa 10! = 3628800 indici e per 20 (rullo di tamburi) 2432902008176640000 indici. Questo è un numero ridicolmente grande, se mettiamo un punto per ogni indice di un mm per parte, ci vorranno 94 giorni di raggio luminoso per passare tutti i punti. Tutto sommato, non ;-)

No.

Non è pratico indicizzare "tutto", ma puoi indicizzarne "la maggior parte".

Ecco la cosa. Se una tabella ha Ncolonne, il numero di indici possibili è N!. Diciamo che una tabella ha 10 colonne, quindi non hai solo 10indici possibili, ma 10!. Cioè ... 3.628.800 ... su un singolo tavolo. Questo è un sacco di spazio su disco, I / O del disco, cache e tempi di ricerca.

Perché? Alcuni motivi:

• Gli indici Lightwwight sono generalmente memorizzati nella cache, cosa che li rende veloci. Se ne hai 3 milioni, NON verranno memorizzati nella cache.

• L'ottimizzatore SQL potrebbe impiegare molto tempo a decidere quale è meglio utilizzare, specialmente quando si utilizzano i join.

• L'ottimizzatore SQL può rinunciare a utilizzare l'algoritmo completo e provare invece un algoritmo euristico. Questo potrebbe essere "meno che ottimale". PostgreSQL, ad esempio, ha diverse opzioni per "query di tabella meno di 8" e "query di tabella più di 8".

• Gli indici dovrebbero essere più leggeri dell'heap. Se stai indicizzando tutto, l'indice diventa pesante come l'heap ... qualcosa che sconfigge lo scopo dell'indice.

No, probabilmente non avrà un impatto negativo sulle SELECTquery, ma

• Ciò causerà un elevato utilizzo del disco.
• Sarà enormemente aumentare il INSERTcosto.
• La maggior parte dei tuoi indici non verrà mai utilizzata.
• Molte WHEREespressioni di condizione non usano ancora gli indici, principalmente quelli più complessi.
• Il conteggio degli indici richiesti aumenterà esponenzialmente con il conteggio delle colonne. Cioè se hai, ad esempio, 8 colonne, hai bisogno di 256 indici per tutte le possibili combinazioni.