Il numero di colonne influisce sulle prestazioni della query?

Question

CASO 1: Ho una tabella con 30 colonne e interrogo utilizzando 4 colonne nella clausola where.

CASO 2: Ho una tabella con 6 colonne e interrogo utilizzando 4 colonne nella clausola where.

Qual è la differenza di prestazioni in entrambi i casi?

Per esempio devo tabella

table A 
{ 
    b varchar(10), 
    c varchar(10), 
    d varchar(10), 
    e varchar(10), 
    f varchar(10), 
    g varchar(10), 
    h varchar(10) 

} 

SELECT b,c,d 
FROM A 
WHERE f='foo' 

create table B 
{ 
    b varchar(10), 
    c varchar(10), 
    d varchar(10), 
    e varchar(10), 
    f varchar(10) 

} 

SELECT b,c,d 
FROM B 
WHERE f='foo' 

entrambi A e B hanno tabella stessa struttura significa unica differenza nel numero di colonna e colonna utilizzata in cui condizione è anche lo stesso e colonna nella selezione è anche lo stesso. la differenza è che la tabella B ha solo alcune colonne non utilizzate che non vengono utilizzate in select e dove condizione in questo caso c'è qualche differenza nelle prestazioni di entrambe le query?

Answer 1

Il principale beneficio di tornare un minor numero di colonne in una SELECT è che SQL potrebbe essere in grado di evitare la lettura della tabella/cluster, e invece, se è in grado di recuperare tutti i dati selected da un indice (sia come colonne indicizzate e/o colonne incluse nel caso di un indice di copertura). Le colonne utilizzate nel predicato, ovvero f nell'esempio, DEVONO essere nelle colonne indicizzate dell'indice.

Nel caso generale, v'è anche una secondaria beneficio a tornare un minor numero di colonne da una SELECT, in modo da ridurre qualsiasi sovraccarico di I/O, soprattutto se v'è una rete lenta tra il server di database e l'applicazione consuma i dati, vale a dire che è buona prassi restituire sempre e solo le colonne effettivamente necessarie e evitare di utilizzare SELECT *.

Edit: In risposta al messaggio aggiornata del PO:

Senza indici a tutti, sia le query faranno le scansioni di tabella. Dato che Table B ha meno colonne di Table A, le righe per pagina (densità) saranno maggiori su B e quindi B sarà leggermente più veloce in quanto SQL richiederà meno pagine.

Tuttavia, con indici come sotto

• indice A(f) INCLUDE (b,c,d)
• indice B(f) INCLUDE (b,c,d)

Le prestazioni dovrebbero essere identiche per le query (assumendo stessi dati di entrambe le tabelle), proposta che SQL colpirà gli indici che ora hanno una larghezza di colonna e densità di righe simili.

Modifica

alcuni altri piani:

• indice sul B(f) senza altre colonne chiave o INCLUDE, o con una serie incompleta di INCLUDE colonne (vale a direuno o più dei b, c or d sono mancanti):

SQL Server sarà probabilmente bisogno di fare un Key or RIDLookup come anche se si usa l'indice, ci sarà una necessità di "unire" tornare al tavolo per recuperare i dispersi colonne nella clausola select. (La ricerca dipende se la tabella ha una PK cluster o meno)

• lisci indice non cluster in B(f,b,c,d)

Questo sarà ancora molto performante, come l'indice verrà utilizzato e la tavola evitato, ma won't be quite as good as the covering index, perché la densità dell'albero dell'indice sarà inferiore a causa delle colonne chiave aggiuntive nell'indice.

Answer 2

Non ci saranno differenze di prestazioni in base alla posizione della colonna. Ora la costruzione del tavolo è una storia diversa, ad es. numero di righe, indici, numero di colonne, ecc.

Lo scenario di cui si sta parlando in cui si confronta la posizione della colonna nelle due tabelle è come quasi confrontare le mele con le arance, perché ci sono così tante variabili diverse oltre la posizione della colonna.

Answer 3

Dipende dalla larghezza della tabella (byte per riga), da quante righe nella tabella e dall'eventuale presenza di indici nelle colonne utilizzate dalla query. Nessuna risposta definitiva senza queste informazioni. Tuttavia, più colonne nella tabella, è probabile che sia più ampia. Ma l'effetto di un indice corretto è molto più significativo dell'effetto delle dimensioni della tabella.

Answer 4

A meno che non si disponga di una differenza di set di colonne molto ampia senza alcun indice utilizzato (quindi una scansione di tabella) si dovrebbe notare poca differenza nelle prestazioni. Detto questo, è sempre utile/generoso restituire il minor numero possibile di colonne per soddisfare i propri bisogni. Il problema qui è che è possibile ottenere una maggiore benifit restituendo le colonne necessarie anziché un secondo recupero di database per altre colonne.

• Ottenere ciò che è necessario
• evitare seconda query di database sullo stesso tavolo per stesse righe
• utilizzare un indice sulla colonna di selezione (s) (clausola WHERE limitatore)
• limitare le colonne se non lo fai ne hanno bisogno per migliorare l'efficienza della memoria del server dati/paging

Answer 5

Provalo e guarda!

Ci sarà una differenza di prestazioni, tuttavia il 99% delle volte non lo noterai, di solito non sarai nemmeno in grado di rilevarlo!

Non si può nemmeno garantire che la tabella con meno colonne sarà più veloce - se si preoccupa, provate e vedete.

spazzatura tecniche: (dal punto di vista di Microsoft SQL Server)

Con il presupposto che in tutti gli altri aspetti (indicatori, conteggi delle righe, i dati contenuti nelle colonne 6 comuni ecc ...) il le tabelle sono identiche, quindi l'unica vera differenza sarà che la tabella più grande è distribuita su più pagine su disco/in memoria.

Il server SQL tenta solo di leggere i dati assolutamente necessari, tuttavia caricherà sempre un'intera pagina alla volta (8 KB). Anche con la stessa quantità di dati richiesti come output della query, se tali dati sono distribuiti su più pagine, è necessario più IO.

Detto questo, il server SQL è incredibilmente efficiente con l'accesso ai dati, pertanto è improbabile che si verifichi un impatto notevole sulle prestazioni, tranne in circostanze estreme.

Inoltre, è anche probabile che la query verrà eseguita rispetto all'indice anziché alla tabella e quindi con indici esattamente della stessa dimensione è probabile che la modifica sia .