it-swarm.it

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 comandi SQL perché è più efficiente per SELECT colonne specificamente necessarie.

Se ho bisogno di SELECT ogni 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.

PDATE: Probabilmente dovrei specificare che l'unica situazione in cui vorrei davvero voler fare un SELECT * è quando seleziono i dati da una tabella in cui so che tutte le colonne dovranno sempre essere recuperate, 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 usato per ragioni tecniche molto più che io abbia mai pensato.

155
Dan Herbert

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 copertura dell'indice errata

È 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.

158
Jon Galloway

Dato tuo specifica che sei 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 cambiamenti di prestazioni e 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.

Equilibrare questo con il potenziale risparmio di specificare le colonne rispetto a un * 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 è alcun risparmio in quanto l'espansione del * deve avvenire comunque, il che significa che consultare comunque 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 in ROM (succede), quindi 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 significano che alcune nuove colonne potrebbero sembra che potrebbe influenzare notevolmente la query.

Il mio consiglio è che dovresti SELEZIONA 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 cambiamenti subdoli sono le denormalizzazioni per prestazioni altrove nel sistema o campi definiti dall'utente.

57
IDisposable

È 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.

33
Giorgi

Ci sono quattro grandi motivi per cui select * è una brutta cosa:

  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.

30
pkh

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

9
ilitirit

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 es. siti web gestiti da contenuti rivolti al pubblico) usando un framework comune, piuttosto che creare una complessa applicazione una tantum; 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.

7
Herb Caudill

SELEZIONARE * è 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 qualche 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.

6
VladV

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.

4
Yann Ramin

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 tue procedure, viste, ecc. Memorizzati - è semplice. Basta scaricare uno script CREATE per il tuo schema DB e cercare il testo attraverso di esso.

4

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 ci si aggira usando 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.

4
Matthew Abbott

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 è solo 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 * ...", questo è 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/sforzo nel specificare i campi piuttosto che spendere molto più tempo e sforzo per rimuovere i bug nelle visualizzazioni o ottimizzare l'app.

3
Alexandre Brasil

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 la query con i nomi di colonna elencati in modo esplicito.

Non speculare sulle prestazioni, misuralo!

L'elenco esplicito è di grande aiuto quando hai una colonna che contiene dati di grandi dimensioni (come il corpo di un post o un articolo) e non ne hai bisogno in una determinata query. Quindi, non restituendolo nella risposta, il server DB può risparmiare tempo, larghezza di banda e velocità effettiva del disco. Anche il risultato della query sarà più piccolo, il che è utile per qualsiasi cache delle query.

3
Paweł Hajdan

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.

3
Nick Berardi

È sempre meglio specificare le colonne di cui hai bisogno, 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.

3
BrewinBombers

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.

2
Jorge Córdoba

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).

2
kennytm

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).

2
Don

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 abbia bisogno di ottenere tutti i campi usando * perché non sai ancora quali campi esistono (pensa a una struttura di database molto dinamica).

Un altro svantaggio dell'uso 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.

2
user9385

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.

1
Keith

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 cercando di capire cosa è andato storto.

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

1
dpollock

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 Word). 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.

1
HLGEM

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.

1
Faisal

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

1
Mark Etable

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.

1
Mike

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.

1
Mark

La validità dell'efficienza dipende molto dalle dimensioni dei set di dati di produzione (e dal loro tasso di crescita). Se i tuoi set di dati non saranno così grandi e non cresceranno così rapidamente, potrebbe non esserci un grande vantaggio in termini di prestazioni nella selezione di singole colonne.

Con set di dati più grandi e velocità più elevate di crescita dei dati, il vantaggio in termini di prestazioni diventa sempre più importante.

Per vedere graficamente se c'è qualche differenza, suggerirei di utilizzare l'analizzatore di query per vedere il piano di esecuzione della query per un SELECT * e l'equivalente SELECT col1, col2, ecc. Questo dovrebbe dirti quale delle due query è più efficiente. Potresti anche generare alcuni dati di test di volumi variabili per vedere quali sono i tempi.

0
Scott Lawrence

Verrò sbattuto per questo, ma faccio una selezione * perché quasi tutti i miei dati vengono recuperati dalle viste di SQL Server che precombinano i valori necessari da più tabelle in un'unica vista di facile accesso.

Voglio quindi tutte le colonne dalla vista che non cambieranno quando vengono aggiunti nuovi campi alle tabelle sottostanti. Questo ha l'ulteriore vantaggio di permettermi di cambiare la provenienza dei dati. Il campo A nella vista può essere calcolato in una volta e quindi posso cambiarlo in statico. In entrambi i casi, View mi fornisce FieldA.

Il bello è che consente al mio livello dati di ottenere set di dati. Quindi li passa al mio BL che può quindi creare oggetti da loro. La mia app principale conosce e interagisce solo con gli oggetti. Permetto persino ai miei oggetti di auto-crearsi quando viene superato un datarow.

Certo, sono l'unico sviluppatore, quindi aiuta anche :)

0
klkitchens

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 *"

0
cazlab

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 con nome sono uguali al tempo di elaborazione se non di più. Non ottimizzare prematuramente ;-)

0
DamienG

La differenza principale tra i due è la quantità di dati trasmessi avanti e indietro. Qualsiasi argomento sulla differenza di tempo è fondamentalmente errato nel fatto che "select *" e "select col1, ..., colN" danno come risultato lo stesso lavoro relativo eseguito dal motore DB. Tuttavia, la trasmissione di 15 colonne per riga rispetto a 5 colonne per riga rappresenta una differenza di 10 colonne.

0
Jeff Hubbard

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.
0
Erik

Vedo che diverse persone sembrano pensare che ci voglia molto più tempo per specificare le colonne. Dal momento che è possibile trascinare l'elenco delle colonne dal browser degli oggetti, ci vuole forse un minuto in più per specificare le colonne (questo è se hai molte colonne e hai bisogno di passare un po 'di tempo a metterle su righe separate) nella query. Perché la gente pensa che richieda così tanto tempo?

0
HLGEM

Consiglio sempre di specificare le colonne necessarie, nel caso in cui lo schema cambi e non sia necessaria la colonna aggiuntiva.

Inoltre, qualificare i nomi delle colonne con il nome della tabella. Questo è fondamentale quando la query contiene join. Senza le qualifiche della tabella, può essere difficile ricordare quale colonna provenga da quale tabella e l'aggiunta di una colonna con nomi simili a una delle altre tabelle può interrompere la query.

0
mxsscott

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 che non sono 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 ...

0
Lahiru Cooray

È particolarmente importante che le prestazioni non utilizzino select * quando si ha un join perché per definizione almeno due campi contengono gli stessi dati. Non si desidera sprecare risorse di rete inviando i dati non necessari dal server di database all'applicazione o al server Web. Può sembrare più facile usare select * ma è una cattiva pratica. Poiché è facile trascinare i nomi delle colonne nella query, basta farlo.

Un altro problema che si verifica quando si utilizza select * è che ci sono idioti che scelgono di aggiungere nuovi campi al centro della tabella (sempre una cattiva pratica), se si utilizza select * come base per un inserimento, improvvisamente il proprio ordine di colonna potrebbe essere sbagliato e potresti provare a inserire il numero di previdenza sociale nell'onorario (la quantità di denaro che un oratore potrebbe essere pagato per scegliere un esempio non casuale) che potrebbe essere una brutta cosa per l'integrità dei dati. Anche se la selezione non è un inserto, appare dannosa per il cliente quando i dati si trovano improvvisamente nell'ordine logoro sul report o sulla pagina Web.

Penso che nessuna circostanza quando si utilizza select * sia preferibile all'utilizzo di un elenco di colonne. Potresti pensare che sia più facile da mantenere, ma in realtà non lo è e farà sì che la tua applicazione diventi più lenta senza motivo quando i campi che non ti servono vengono aggiunti alle tabelle. Dovrai anche affrontare il problema di risolvere cose che non si sarebbero interrotte se avessi usato un elenco di colonne, quindi il tempo che risparmi non aggiungendo una colonna viene utilizzato per fare questo.

0
HLGEM

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.

0
siculars

Ricorda anche i cambiamenti. Oggi, Seleziona * seleziona solo le colonne di cui hai bisogno, ma domani potrebbe anche selezionare quella colonna varbinary (MAX) che ho appena aggiunto senza dirtelo, e ora stai anche recuperando tutti i 3,18 Gigabyte di dati binari che non erano nella tabella di ieri.

0
Michael Stum

Pensiamo a quale è più veloce. Se puoi selezionare solo i dati di cui hai bisogno, allora è più veloce. Tuttavia, durante i test è possibile estrarre tutti i dati per giudicare quali dati possono essere filtrati in base alle esigenze aziendali.

0
mikedopp

Ci sono casi in cui SELECT * è buono per scopi di manutenzione, ma in generale dovrebbe essere evitato.

Si tratta di casi speciali come viste o procedure memorizzate in cui si desidera che le modifiche nelle tabelle sottostanti si propaghino senza la necessità di andare e cambiare ogni vista e proc memorizzato che utilizza la tabella. Anche in questo caso, ciò può causare problemi, come nel caso in cui si abbiano due viste unite. Una tabella sottostante cambia e ora la vista è ambigua perché entrambe le tabelle hanno una colonna con lo stesso nome. (Nota che ciò può accadere ogni volta che non qualifichi tutte le tue colonne con prefissi di tabella). Anche con prefissi, se hai un costrutto come:

SELEZIONA A ., B. - puoi avere problemi in cui il client ora ha difficoltà a selezionare il campo giusto.

In generale, non utilizzo SELECT * a meno che non stia prendendo una decisione consapevole sul progetto e contando sui rischi correlati per essere bassi.

0
Cade Roux

Il SELECT *potrebbe va bene se in realtà avevi bisogno di tutte le colonne, ma dovresti comunque elencarle tutte singolarmente. Non dovresti certamente selezionare tutte le righe da una tabella, anche se l'app e il DB si trovano sullo stesso server o rete. Il trasferimento di tutte le righe richiederà tempo, soprattutto con l'aumentare del numero di righe. Dovresti avere almeno una clausola where che filtra i risultati e/o sfoglia i risultati per selezionare solo il sottoinsieme di righe che devono essere visualizzate. Esistono diversi strumenti ORM a seconda della lingua dell'app che si sta utilizzando per fornire assistenza durante l'interrogazione e il paging del sottoinsieme di dati necessari. Ad esempio, in .NET Linq to SQL, Entity Framework e nHibernate ti aiuteranno in questo.

0
bkaid

Usa nomi di campi specifici, quindi se qualcuno ti modifica la tabella, non otterrai risultati imprevisti. A proposito: specificare SEMPRE i nomi dei campi quando si esegue un inserimento, quindi se è necessario aggiungere una colonna in un secondo momento, non è necessario tornare indietro e correggere il programma e modificare contemporaneamente il database nella versione di produzione.

0
stu

Se ti preoccupi della velocità, assicurati di usare le dichiarazioni preparate. Altrimenti, sono d'accordo con ilitirit che i cambiamenti sono ciò per cui ti proteggi.

/ Allan

0
Allan Wind

Trovo che elencare i nomi delle colonne sia particolarmente importante se è probabile che altri sviluppatori lavorino con il codice o che il database cambi, in modo da ottenere sempre dati coerenti.

0
Sam Cogan

Questo è un vecchio post, ma ancora valido. Per riferimento, ho una query molto complicata composta da:

  • 12 tavoli
  • 6 join di sinistra
  • 9 join interni
  • 108 colonne totali su tutte e 12 le tabelle
  • Ho solo bisogno di 54 colonne
  • Una clausola Order By a 4 colonne

Quando eseguo la query utilizzando Select *, sono necessari in media 2869 ms. Quando eseguo la query utilizzando Select, sono necessari in media 1513 ms.

Le righe totali restituite sono 13.949.

Non c'è dubbio che selezionare i nomi delle colonne significa prestazioni più veloci rispetto a Seleziona *

Per interrogare direttamente il DB (come ad esempio un prompt sqlplus o tramite uno strumento di amministrazione db), selezionare * va generalmente bene - ti fa risparmiare la fatica di scrivere tutte le colonne.

D'altra parte, nel codice dell'applicazione è meglio enumerare le colonne. Ciò ha diversi vantaggi:

  • Il codice è più chiaro
  • Conoscerai l'ordine in cui ritornano i risultati (questo potrebbe essere o non essere importante per te)
0
Morikal

Bene, dipende davvero dalle tue metriche e dal tuo scopo:

  1. Se hai 250 colonne e vuoi (anzi) selezionarle tutte, usa seleziona * se vuoi tornare a casa lo stesso giorno :)
  2. Se la tua codifica necessita di flessibilità e la tabella in questione è ancora piccola, seleziona * ti aiuta a programmare più velocemente e a mantenerla più facilmente.
  3. Se desideri una progettazione e prestazioni affidabili:
    • scrivi i nomi delle tue colonne se sono solo alcuni, oppure
    • scrivere uno strumento che ti consenta di selezionare/generare facilmente i nomi delle tue colonne

Come regola generale, quando devo selezionare tutte le colonne, utilizzerei "select *" a meno che non abbia un motivo molto specifico per fare diversamente (in più, penso che sia più veloce sui tavoli con molte, molte colonne)

E, ultimo ma non meno importante, come si desidera aggiungere o eliminare una colonna nella tabella per influire sul codice o sulla sua manutenzione?

0
Notitze