Vantaggi prestazionali quando la query SQL è limitata rispetto alla chiamata dell'intera riga?

Question

Qual è il vantaggio in termini di prestazioni selezionando solo il campo richiesto nella query anziché eseguire la query dell'intera riga? Ad esempio, se ho una riga di 10 campi ma ho bisogno solo di 5 campi nel display, vale la pena interrogare solo quei 5? qual è il vantaggio in termini di prestazioni con questa limitazione rispetto al rischio di dover tornare indietro e aggiungere campi nella query sql in un secondo momento, se necessario?

Answer 1

Non è solo l'aspetto dei dati extra che devi considerare. La selezione di tutte le colonne annullerà l'utilità di coprire gli indici, poiché sarà richiesta una ricerca di segnalibri nell'indice (o tabella) cluster.

Answer 2

Dipende da quante righe sono selezionate e da quanta memoria consumano quei campi extra. Può funzionare molto più lentamente se sono presenti più campi di testo / BLOB o se sono selezionate più righe.

In che modo l'aggiunta di campi in un secondo momento rappresenta un rischio? la modifica delle query per adattarsi alle mutevoli esigenze è una parte naturale del processo di sviluppo.

Answer 3

L'unico vantaggio che conosco della denominazione esplicita delle colonne nell'istruzione select è che se una colonna utilizzata dal codice viene rinominata, l'istruzione select avrà esito negativo prima del codice. Ancora meglio se l'istruzione select si trova all'interno di un proc, il proc e lo script DB non verranno compilati. Ciò è molto utile se si utilizzano strumenti come VS DB Edition per compilare / verificare script DB. Altrimenti la differenza di prestazioni sarebbe trascurabile.

Answer 4

Il numero di campi recuperati è un effetto del secondo ordine sulle prestazioni rispetto al grande overhead della stessa richiesta SQL: andare fuori processo, attraverso la rete a un altro host e possibilmente su disco su quell'host richiede molti più cicli che spalare qualche byte in più di dati.

Ovviamente se i campi extra includono un blob da megabyte, l'equazione è distorta. Ma la mia esperienza è che il sovraccarico della transazione è dello stesso ordine, o maggiore, rispetto ai dati effettivi recuperati. Ricordo vagamente da molti anni fa che un "vuoto" NOP La richiesta TNS è di circa 100 byte sul filo.

Answer 5

Se il server SQL non è lo stesso computer da cui stai eseguendo la query, selezionando le colonne aggiuntive trasferisci più dati sulla rete (che può essere un collo di bottiglia), senza dimenticare che deve leggere più dati dal disco , alloca più memoria per contenere i risultati.

Non c'è nulla che possa causare un problema da solo, ma sommare le cose e tutti insieme causano problemi di prestazioni. Ogni piccolo aiuto è utile quando hai molte query o dati.

Immagino che dovresti aggiungere i campi alla query in seguito, il che probabilmente significa cambiare il codice, ma in genere devi aggiungere altro codice per gestire comunque campi extra.