Dovrei usare una grande istruzione SQL Select o più piccole?

Question

Sto costruendo una pagina PHP con i dati inviati da MySQL.

È meglio avere?

• 1 SELECT query con 4 join di tabella o
• 4 piccoli SELECT query senza unione di tabelle;Seleziono da un ID

Qual è il più veloce e quali sono i pro/contro di ciascun metodo?Ho solo bisogno di una riga per ogni tabella.

Answer 1

Dovresti eseguire uno strumento di profilazione se sei veramente preoccupato perché dipende da molte cose e può variare, ma di norma è meglio avere meno query compilate e meno viaggi di andata e ritorno nel database.

Assicurati di filtrare le cose nel miglior modo possibile utilizzando le clausole where e join on.

Ma onestamente, di solito non ha importanza poiché probabilmente non verrai colpito così duramente rispetto a ciò che può fare il database, quindi a meno che l'ottimizzazione non sia la tua specifica, non dovresti farlo prematuramente e fare ciò che è più semplice.

Answer 2

Quando utilizzi JOIN anziché più query, consenti al database di applicare le sue ottimizzazioni.Stai anche potenzialmente recuperando righe che non ti servono (se dovessi sostituire un INNER join con più selezioni), il che aumenta il traffico di rete tra il server dell'app e il server del database.Anche se sono sulla stessa scatola, questo è importante.

Answer 3

In genere, è meglio avere un'istruzione SELECT.Uno dei motivi principali per disporre di database è che sono veloci nell'elaborazione delle informazioni, in particolare se sono in formato query.

Se c'è qualche svantaggio in questo approccio, è che ci sono alcuni tipi di analisi che non è possibile eseguire con una grande istruzione SELECT.I puristi dell'RDBMS insisteranno sul fatto che si tratta di un problema di progettazione del database, nel qual caso tornerai al mio suggerimento originale.

Answer 4

Potrebbe dipendere da cosa fai con i dati dopo averli recuperati dal DB.Se utilizzi ciascuno dei quattro risultati in modo indipendente, sarebbe più logico e chiaro avere quattro istruzioni SELECT separate.D'altra parte, se utilizzi tutti i dati insieme, ad esempio per creare una riga unificata in una tabella o qualcosa del genere, allora opterei per i singoli SELECT e JOIN.

Ho svolto un po' di lavoro su PHP/MySQL e trovo che anche per query su tabelle enormi con tonnellate di JOIN, il database è abbastanza bravo a ottimizzare, se disponi di indici intelligenti.Quindi, se prendi sul serio le prestazioni, inizia a leggere ottimizzazione e indicizzazione delle query.

Answer 5

Direi 1 query con il join.In questo modo è necessario colpire il server solo una volta.E se le tue tabelle sono unite tramite indici, dovrebbe essere veloce.

Answer 6

Bene, sotto Oracle vorresti sfruttare la memorizzazione nella cache delle query e se hai molte piccole query che stai eseguendo nell'elaborazione sequenziale, farebbe schifo se l'ultima query spingesse la prima fuori dalla cache... giusto in tempo per poter fare un giro ed eseguire nuovamente la prima query (ovviamente con valori di parametro diversi) al passaggio successivo.

Stavamo costruendo un file di output XML utilizzando le procedure memorizzate Java e abbiamo scoperto che i tempi di andata e ritorno per ogni singola query ci stavano divorando vivi.Abbiamo scoperto che era molto più veloce ottenere tutti i dati nel minor numero di query possibile, quindi inserire tali valori nel DOM XML secondo necessità.

L'unico svantaggio è che il codice Java era un po' meno elegante, poiché il recupero dei dati era ormai distante dal suo utilizzo.Ma dovevamo generare un file XML complesso e di grandi dimensioni nel minor tempo possibile, quindi abbiamo dovuto ottimizzare la velocità.

Answer 7

Tuttavia, fai attenzione quando hai a che fare con una tabella di unione.In base alla mia esperienza, sebbene un singolo join possa essere utile nella maggior parte delle situazioni, quando sono coinvolte tabelle di unione puoi incorrere in situazioni strane.