Qual è il più veloce / migliore? SELEZIONA * o SELEZIONA colonna1, colonna2, colonna3, ecc

Ho sentito che SELECT *è generalmente una cattiva pratica da usare quando si scrivono i comandi SQL perché è più efficiente per le SELECTcolonne che sono specificamente necessarie.

Se ho bisogno di SELECTogni colonna in una tabella, dovrei usare

SELECT * FROM TABLE

o

SELECT column1, colum2, column3, etc. FROM TABLE

L'efficienza conta davvero in questo caso? Penso che SELECT *sarebbe più ottimale internamente se avessi davvero bisogno di tutti i dati, ma lo sto dicendo senza una reale comprensione del database.

Sono curioso di sapere qual è la migliore pratica in questo caso.

UPDATE: probabilmente dovrebbe specificare che l'unica situazione in cui avrei davvero voglia di fare una SELECT *è quando sto la selezione dei dati da una tabella dove so avranno sempre bisogno di essere recuperate tutte le colonne, anche quando vengono aggiunte nuove colonne.

Date le risposte che ho visto, tuttavia, questa sembra ancora una cattiva idea e SELECT *non dovrebbe mai essere usata per ragioni molto più tecniche che io abbia mai pensato.

Uno dei motivi per cui la selezione di colonne specifiche è migliore è che aumenta la probabilità che SQL Server possa accedere ai dati dagli indici anziché interrogare i dati della tabella.

Ecco un post che ho scritto al riguardo: il vero motivo per cui le query di selezione sono una cattiva copertura dell'indice

È anche meno fragile da modificare, poiché qualsiasi codice che consuma i dati otterrà la stessa struttura di dati indipendentemente dalle modifiche apportate allo schema della tabella in futuro.

Dato il tuo specifica che si sta selezionando tutte le colonne, c'è poca differenza in questo momento . Renditi conto, tuttavia, che gli schemi del database cambiano. Se usi, SELECT *otterrai nuove colonne aggiunte alla tabella, anche se con ogni probabilità, il tuo codice non è pronto per usare o presentare quei nuovi dati. Ciò significa che stai esponendo il tuo sistema a imprevisti e cambiamenti di funzionalità.

Potresti essere disposto a scartare questo come costo minore, ma ti rendi conto che le colonne che non ti servono ancora devono essere:

1. Leggi dal database
2. Inviato attraverso la rete
3. Sbattuto nel tuo processo
4. (per tecnologie di tipo ADO) Salvato in una tabella di dati in memoria
5. Ignorato e scartato / immondizia raccolta

L'articolo n. 1 ha molti costi nascosti, tra cui l'eliminazione di un potenziale indice di copertura, il caricamento di pagine di dati (e il blocco della cache del server), con conseguenti blocchi di riga / pagina / tabella che potrebbero altrimenti essere evitati.

Bilanciare questo con i potenziali risparmi di specificare le colonne rispetto a *e gli unici potenziali risparmi sono:

1. Il programmatore non ha bisogno di rivisitare l'SQL per aggiungere colonne
2. Il trasporto di rete di SQL è più piccolo / più veloce
3. Tempo di analisi / validazione delle query di SQL Server
4. Cache del piano di query di SQL Server

Per l'articolo 1, la realtà è che stai per aggiungere / modificare il codice per utilizzare qualsiasi nuova colonna che potresti aggiungere comunque, quindi è un lavaggio.

Per l'articolo 2, la differenza è raramente sufficiente per spingerti in una dimensione di pacchetto o numero di pacchetti di rete diversi. Se arrivate al punto in cui il tempo di trasmissione delle istruzioni SQL è il problema principale, probabilmente dovrete prima ridurre la frequenza delle istruzioni.

Per l'articolo 3, NON vi sono risparmi in quanto l'espansione *deve avvenire comunque, il che significa comunque consultare lo schema delle tabelle. Realisticamente, elencare le colonne comporta lo stesso costo perché devono essere convalidate rispetto allo schema. In altre parole, questo è un lavaggio completo.

Per l'articolo 4, quando si specificano colonne specifiche, la cache del piano di query potrebbe ingrandirsi, ma solo se si ha a che fare con diversi set di colonne (che non è quello specificato). In questo caso, vuoi voci di cache diverse perché vuoi piani diversi secondo necessità.

Quindi, tutto si riduce, a causa del modo in cui è stata specificata la domanda, alla resilienza del problema a fronte di eventuali modifiche dello schema. Se stai masterizzando questo schema nella ROM (succede), allora un *è perfettamente accettabile.

Tuttavia, la mia linea guida generale è che dovresti selezionare solo le colonne di cui hai bisogno, il che significa che a volte sembrerà che tu le stia chiedendo tutte, ma DBA ed evoluzione dello schema indicano che potrebbero apparire alcune nuove colonne che potrebbero influenzare notevolmente la query .

Il mio consiglio è di selezionare SEMPRE colonne specifiche . Ricorda che diventi sempre bravo in quello che fai, quindi prendi l'abitudine di farlo nel modo giusto.

Se ti stai chiedendo perché uno schema potrebbe cambiare senza cambiare il codice, pensa in termini di registrazione dell'audit, date di scadenza / effettive e altre cose simili che vengono aggiunte dai DBA per sistematicamente per problemi di conformità. Un'altra fonte di modifiche subdole sono le denormalizzazioni per prestazioni altrove nel sistema o campi definiti dall'utente.

È necessario selezionare solo le colonne necessarie. Anche se hai bisogno di tutte le colonne è comunque meglio elencare i nomi delle colonne in modo che il server sql non debba interrogare la tabella di sistema per le colonne.

Inoltre, l'applicazione potrebbe interrompersi se qualcuno aggiunge colonne alla tabella. Il tuo programma otterrà colonne che non si aspettava troppo e potrebbe non sapere come elaborarle.

A parte questo, se la tabella ha una colonna binaria, la query sarà molto più lenta e utilizzerà più risorse di rete.

Ci sono quattro grandi ragioni che select *è una cosa negativa:

1. Il motivo pratico più significativo è che costringe l'utente a conoscere magicamente l'ordine in cui verranno restituite le colonne. È meglio essere espliciti, il che ti protegge anche dal cambio del tavolo, che segue piacevolmente ...

2. Se il nome di una colonna che stai usando cambia, è meglio prenderlo in anticipo (nel punto della chiamata SQL) piuttosto che quando stai cercando di usare la colonna che non esiste più (o che ha avuto il suo nome cambiato, ecc. )

3. Elencare i nomi delle colonne rende il tuo codice molto più auto-documentato e quindi probabilmente più leggibile.

4. Se stai trasferendo su una rete (o anche se non lo sei), le colonne che non ti servono sono solo sprechi.

Specificare l'elenco di colonne è di solito l'opzione migliore perché l'applicazione non sarà interessata se qualcuno aggiunge / inserisce una colonna nella tabella.

Specificare i nomi delle colonne è decisamente più veloce, per il server. Ma se

1. le prestazioni non sono un grosso problema (ad esempio, questo è un database del contenuto del sito Web con centinaia, forse migliaia - ma non milioni - di righe in ogni tabella); E
2. il tuo compito è quello di creare molte piccole applicazioni simili (ad esempio siti web gestiti da contenuti rivolti al pubblico) utilizzando un framework comune, piuttosto che creare una complessa applicazione unica; E
3. la flessibilità è importante (molta personalizzazione dello schema db per ciascun sito);

allora stai meglio con Stick *. Nel nostro framework, l'uso intenso di SELECT * ci consente di introdurre in una tabella un nuovo campo di contenuti gestiti dal sito Web, offrendogli tutti i vantaggi del CMS (versioning, flusso di lavoro / approvazioni, ecc.), Toccando solo il codice in un un paio di punti, anziché un paio di dozzine di punti.

So che i guru del DB mi odieranno per questo - vai avanti, votami in basso - ma nel mio mondo, il tempo degli sviluppatori è scarso e i cicli della CPU sono abbondanti, quindi adeguo di conseguenza ciò che conservo e ciò che spreco.

SELECT * è una cattiva pratica anche se la query non viene inviata su una rete.

1. La selezione di più dati di quelli necessari rende la query meno efficiente: il server deve leggere e trasferire dati extra, quindi richiede tempo e crea un carico non necessario sul sistema (non solo la rete, come altri hanno già detto, ma anche disco, CPU ecc. ). Inoltre, il server non è in grado di ottimizzare la query come potrebbe (ad esempio, utilizzare l'indice di copertura per la query).
2. Dopo un po 'di tempo la struttura della tabella potrebbe cambiare, quindi SELECT * restituirà un diverso set di colonne. Pertanto, l'applicazione potrebbe ottenere un set di dati di struttura imprevista e interrompersi da qualche parte a valle. Dichiarare esplicitamente le colonne garantisce che si ottenga un set di dati di struttura nota o si ottenga un chiaro errore a livello di database (come "colonna non trovata").

Ovviamente, tutto ciò non conta molto per un sistema piccolo e semplice.

Per quanto riguarda le prestazioni, SELECT con colonne specifiche può essere più veloce (non è necessario leggere tutti i dati). Se la tua query utilizza davvero TUTTE le colonne, SELEZIONA con parametri espliciti è comunque preferito. Qualsiasi differenza di velocità sarà sostanzialmente impercettibile e quasi a tempo costante. Un giorno il tuo schema cambierà, e questa è una buona assicurazione per prevenire problemi dovuti a questo.

Molte buone ragioni hanno risposto qui finora, eccone un'altra che non è stata menzionata.

Denominare esplicitamente le colonne ti aiuterà con la manutenzione lungo la strada. Ad un certo punto stai per apportare modifiche o risoluzione dei problemi e ti ritrovi a chiedere "dove diavolo è quella colonna utilizzata".

Se hai i nomi elencati esplicitamente, trovare ogni riferimento a quella colonna - attraverso tutte le procedure, le viste, ecc. Memorizzate - è semplice. Scarica semplicemente uno script CREATE per il tuo schema DB e cerca il testo attraverso di esso.

definendo definitivamente le colonne, perché SQL Server non dovrà effettuare una ricerca sulle colonne per estrarle. Se si definiscono le colonne, SQL può saltare questo passaggio.

È sempre meglio specificare le colonne necessarie, se ci pensi una volta, SQL non deve pensare "wtf is *" ogni volta che esegui una query. Inoltre, in seguito qualcuno potrebbe aggiungere colonne alla tabella che in realtà non ti servono nella tua query e in questo caso starai meglio specificando tutte le tue colonne.

Il problema con "select *" è la possibilità di fornire dati di cui non si ha realmente bisogno. Durante la query effettiva del database, le colonne selezionate non si aggiungono realmente al calcolo. Ciò che è veramente "pesante" è il trasporto di dati al tuo client, e qualsiasi colonna che non ti serve davvero è semplicemente sprecare la larghezza di banda della rete e aumentare il tempo che aspetti che la query ritorni.

Anche se usi tutte le colonne portate da un "seleziona * ...", è solo per ora. Se in futuro cambi il layout della tabella / vista e aggiungi più colonne, inizierai a portarle nelle tue selezioni anche se non ti servono.

Un altro punto in cui un'istruzione "select *" è errata è la creazione della vista. Se crei una vista utilizzando "select *" e successivamente aggiungi colonne alla tabella, la definizione della vista e i dati restituiti non corrisponderanno e dovrai ricompilare le viste affinché possano funzionare nuovamente.

So che scrivere un "select *" è allettante, perché non mi piace davvero specificare manualmente tutti i campi nelle mie query, ma quando il tuo sistema inizia a evolversi, vedrai che vale la pena spendere questo tempo extra / sforzi per specificare i campi piuttosto che spendere molto più tempo e sforzi per rimuovere i bug dalle visualizzazioni o ottimizzare l'app.

Mentre elencare esplicitamente le colonne è buono per le prestazioni, non impazzire.

Quindi, se usi tutti i dati, prova SELECT * per semplicità (immagina di avere molte colonne e fare una query JOIN ... potrebbe diventare terribile). Quindi - misurare. Confronta con query con nomi di colonne elencati in modo esplicito.

Non speculare sulle prestazioni, misurale!

L'elenco esplicito è di grande aiuto quando si dispone di una colonna contenente big data (come il corpo di un post o un articolo) e non è necessaria in una determinata query. Quindi, non restituendolo nella risposta, il server DB può risparmiare tempo, larghezza di banda e velocità effettiva del disco. Il risultato della query sarà inoltre più piccolo, il che è utile per qualsiasi cache delle query.

Dovresti davvero selezionare solo i campi di cui hai bisogno e solo il numero richiesto, ad es

SELECT Field1, Field2 FROM SomeTable WHERE --(constraints)

Al di fuori del database, le query dinamiche corrono il rischio di attacchi di iniezione e dati non validi. In genere si aggira questo utilizzando procedure memorizzate o query con parametri. Inoltre (anche se non è un grosso problema) il server deve generare un piano di esecuzione ogni volta che viene eseguita una query dinamica.

Select è ugualmente efficiente (in termini di velocità) se si utilizzano * o colonne.

La differenza riguarda la memoria, non la velocità. Quando si selezionano più colonne, SQL Server deve allocare spazio di memoria per servire la query, inclusi tutti i dati per tutte le colonne richieste, anche se si utilizza solo una di esse.

Ciò che conta in termini di prestazioni è il piano di esecuzione che a sua volta dipende fortemente dalla clausola WHERE e dal numero di JOIN, OUTER JOIN, ecc ...

Per la tua domanda basta usare SELEZIONA *. Se hai bisogno di tutte le colonne non c'è differenza di prestazioni.

NON è più veloce usare nomi di campi espliciti rispetto a *, se e solo se, è necessario ottenere i dati per tutti i campi.

Il software client non dovrebbe dipendere dall'ordine dei campi restituiti, quindi anche questa è una sciocchezza.

Ed è possibile (anche se improbabile) che tu debba ottenere tutti i campi usando * perché non sai ancora quali campi esistono (pensa a una struttura di database molto dinamica).

Un altro svantaggio dell'utilizzo di nomi di campo espliciti è che se ce ne sono molti e sono lunghi, rende più difficile la lettura del codice e / o del registro delle query.

Quindi la regola dovrebbe essere: se hai bisogno di tutti i campi, usa *, se hai bisogno solo di un sottoinsieme, chiamali esplicitamente.

Il risultato è troppo grande. È lento generare e inviare il risultato dal motore SQL al client.

Il lato client, essendo un ambiente di programmazione generico, non è e non dovrebbe essere progettato per filtrare ed elaborare i risultati (ad esempio la clausola WHERE, la clausola ORDER), poiché il numero di righe può essere enorme (ad esempio decine di milioni di righe).

La denominazione di ogni colonna che prevedi di ottenere nella tua applicazione garantisce anche che l'applicazione non si interrompa se qualcuno altera la tabella, purché le colonne siano ancora presenti (in qualsiasi ordine).

Dipende dalla versione del server DB, ma le versioni moderne di SQL possono memorizzare nella cache il piano in entrambi i modi. Direi di andare con tutto ciò che è più gestibile con il tuo codice di accesso ai dati.

Uno dei motivi per cui è meglio precisare quali colonne desideri è a causa di possibili cambiamenti futuri nella struttura della tabella.

Se stai leggendo i dati manualmente utilizzando un approccio basato sull'indice per popolare una struttura di dati con i risultati della tua query, in futuro quando aggiungi / rimuovi una colonna avrai mal di testa che provano a capire cosa è andato storto.

Quanto a ciò che è più veloce, rimanderò agli altri per la loro esperienza.

Come con la maggior parte dei problemi, dipende da cosa vuoi ottenere. Se si desidera creare una griglia db che consentirà tutte le colonne in qualsiasi tabella, "Seleziona *" è la risposta. Tuttavia, se sono necessarie solo determinate colonne e l'aggiunta o l'eliminazione di colonne dalla query viene eseguita raramente, quindi specificarle singolarmente.

Dipende anche dalla quantità di dati che si desidera trasferire dal server. Se una delle colonne è definita come memo, grafico, BLOB, ecc. E non hai bisogno di quella colonna, è meglio non usare "Seleziona *" o otterrai un sacco di dati che non vuoi e la tua performance potrebbe risentirne.

Per aggiungere ciò che hanno detto tutti gli altri, se tutte le colonne che si stanno selezionando sono incluse in un indice, il set di risultati verrà estratto dall'indice invece di cercare ulteriori dati da SQL.

SELEZIONA * è necessario se si desidera ottenere metadati come il numero di colonne.

Ciò che tutti hanno detto sopra, oltre a:

Se stai cercando un codice gestibile leggibile, fai qualcosa del tipo:

SELEZIONA foo, barra DA widget;

è immediatamente leggibile e mostra l'intento. Se fai quella chiamata, sai cosa stai ricevendo. Se i widget hanno solo colonne foo e bar, quindi selezionare * significa che devi ancora pensare a cosa stai tornando, confermare che l'ordine sia mappato correttamente, ecc. Tuttavia, se i widget hanno più colonne ma sei interessato solo a foo e la barra, quindi il codice diventa disordinato quando si esegue una query per un carattere jolly e quindi si utilizza solo parte di ciò che viene restituito.

E ricorda che se hai un join interno per definizione non hai bisogno di tutte le colonne poiché i dati nelle colonne del join vengono ripetuti.

Non è come elencare le colonne nel server SQl sia difficile o addirittura dispendioso in termini di tempo. Basta trascinarli dal browser degli oggetti (è possibile ottenere tutto in una volta trascinando dalle colonne di parole). Per mettere a segno un impatto permanente sulle prestazioni del sistema (in quanto ciò può ridurre l'uso degli indici e perché l'invio di dati non necessari sulla rete è costoso) e rendere più probabile la presenza di problemi imprevisti quando il database cambia (a volte vengono aggiunte colonne che non vuoi che l'utente lo veda ad esempio) solo per risparmiare meno di un minuto di tempo di sviluppo è miope e poco professionale.

Per quanto riguarda le prestazioni, ho visto commenti che entrambi sono uguali. ma l'aspetto dell'usabilità ci sono alcuni + e -

Quando si utilizza un (selezionare *) in una query e se qualcuno modifica la tabella e aggiunge nuovi campi non necessari per la query precedente, si tratta di un sovraccarico non necessario. E se il campo appena aggiunto è un BLOB o un campo immagine ??? il tempo di risposta alla query sarà quindi molto lento.

D'altra parte se si utilizza un (selezionare col1, col2, ..) e se la tabella viene modificata e aggiunta di nuovi campi e se tali campi sono necessari nel set di risultati, è sempre necessario modificare la query di selezione dopo la modifica della tabella.

Ma suggerisco sempre di utilizzare select col1, col2, ... nelle tue query e modificare la query se la tabella viene modificata in seguito ...

Definisci in modo assoluto le colonne che vuoi SELEZIONARE ogni volta. Non c'è motivo di non farlo e ne vale la pena il miglioramento delle prestazioni.

Non avrebbero mai dovuto dare l'opzione a "SELEZIONA *"

Se hai bisogno di ogni colonna, usa semplicemente SELECT * ma ricorda che l'ordine potrebbe potenzialmente cambiare, quindi quando stai consumando i risultati accedi ad essi per nome e non per indice.

Vorrei ignorare i commenti su come * deve andare a ottenere l'elenco - le probabilità che analizzino e convalidando le colonne denominate è uguale al tempo di elaborazione se non di più. Non ottimizzare prematuramente ;-)

In termini di efficienza di esecuzione non sono a conoscenza di differenze significative. Ma per l'efficienza dei programmatori scriverei i nomi dei campi perché

• Conosci l'ordine se devi indicizzare per numero o se il tuo driver si comporta in modo divertente sui valori BLOB e hai bisogno di un ordine definito
• Leggi solo i campi che ti servono, se dovessi mai aggiungere altri campi
• Si ottiene un errore sql se si scrive in modo errato o si rinomina un campo, non un valore vuoto da un recordset / riga
• Puoi leggere meglio cosa sta succedendo.

ehi, sii pratico. utilizzare select * durante la prototipazione e selezionare colonne specifiche durante l'implementazione e la distribuzione. dal punto di vista del piano di esecuzione, entrambi sono relativamente identici sui sistemi moderni. tuttavia, la selezione di colonne specifiche limita la quantità di dati che devono essere recuperati dal disco, archiviati in memoria e inviati in rete.

in definitiva il piano migliore è selezionare colonne specifiche.