Overhead per MySQL SCEGLIE - meglio utilizzare una o molti in sequenza

Question

C'è una differenza di prestazioni apprezzabili tra l'avere una query SELECT foo, bar, FROM users che restituisce 500 righe, e 500 query SELECT foo, bar, FROM users WHERE id = x provenienti tutto in una volta?

In un'applicazione PHP che sto scrivendo, sto cercando di scegliere tra una sezione di lettura chiara la scrittura di codice che produrrebbe circa 500 istruzioni SELECT; o scrivere una in un modo complesso oscura che avrebbe utilizzato una sola SELECT che restituisce 500 righe.

Io preferirei il modo in cui utilizza, il codice mantenibile chiaro, ma io sono preoccupato del fatto che l'overhead di connessione per ciascuna delle SELECT causerà problemi di prestazioni.

Informazioni sul fondo, nel caso in cui è rilevante: 1) Questo è un modulo Drupal, codificato in PHP 2) Le tabelle in questione si fanno molto pochi inserimenti e aggiornamenti, e raramente sono bloccati 3) SQL JOIN non sono possibili per motivi non pertinenti alla domanda

Grazie!

Answer 1

E 'quasi sempre più veloce per fare una grande partita SELECT e analizzare i risultati nel codice dell'applicazione che fare una massiccia quantità di seleziona per una riga. Vorrei raccomandare che si sceglie di implementare entrambi e li profilo, però. Cercate sempre di ridurre al minimo il numero di ipotesi si deve fare.

Answer 2

Non mi preoccuperei per il sovraccarico di connessione di query mysql troppo, soprattutto se non sta chiudendo il collegamento tra ogni query. Si consideri che se la query crea una tabella temporanea, hai già speso più tempo nella query che il sovraccarico della query ha preso.

Mi piace fare una query SQL complessa, personalmente, ma ho scoperto che le dimensioni delle tabelle, cache delle query MySQL e prestazioni delle query di query che hanno bisogno di fare il controllo dei limiti (anche contro un indice) tutti fanno la differenza.

Suggerisco questo:

1) Stabilire la semplice, corretta linea di base. Ho il sospetto che questo è l'approccio zillion-query. Questo non è sbagliato, e molto probabilmente helfully corretta. Eseguire un paio di volte e guardare la cache query e le prestazioni delle applicazioni. La capacità di mantenere la vostra applicazione mantenibile è molto importante, soprattutto se si lavora con altri manutentori di codice. Inoltre, se si sta interrogando davvero tabelle di grandi dimensioni, piccoli query manterrà la scalabilità.

2) Codice del complesso query. confrontare i risultati per la precisione, e quindi il tempo. Quindi utilizzare durante il la query per vedere quali sono le righe analizzate sono. Spesso ho scoperto che se ho un JOIN, o un dove x! = Y, o di una condizione che crea una tabella temporanea, le prestazioni di query potrebbe ottenere piuttosto male, soprattutto se sono in una tabella che sta ottenendo sempre aggiornato. Tuttavia, ho anche scoperto che una query complessa potrebbe non essere corretto, e anche che una query complessa può più facilmente rompere come applicazione cresce. query complesse in genere la scansione di grandi insiemi di righe, spesso creando tabelle temporanee e invocano scansioni using where. Più grande è il tavolo, il più costoso questi get. Inoltre, si potrebbe avere considerazioni squadra dove query complesse non si adattano i punti di forza del team.

3) Condividere i risultati con il team.

query complesse sono meno probabilità di colpire la cache delle query mysql, e se sono abbastanza grandi, non li cache. (Si vuole salvare la cache delle query mysql per frequentemente colpito query.) Inoltre, di query in cui i predicati che devono eseguire la scansione l'indice non farà pure. (X! = Y, x> y, x SELECT foo, bar FROM users WHERE foo != 'g' and mumble < '360' finisce per fare scansioni. (Il costo di interrogazione sovraccarico potrebbe essere trascurabile in questo caso.)

Piccoli query possono spesso completa senza la creazione di tabelle temporanee solo ottenendo tutti i valori dall'indice, a condizione che i campi si sta selezionando e della previsione sulle sono indicizzati. Quindi le prestazioni di query di SELECT foo, bar FROM users WHERE id = x è davvero grande (specialmente se le colonne foo e bar sono indicizzati come, alias alter table users add index ix_a ( foo, bar );.)

Altri buoni modi per aumentare le prestazioni nella vostra applicazione potrebbe essere quella di memorizzare nella cache quei piccoli risultati della query nell'applicazione (se del caso), o fare lavori batch di una query vista materializzata. Inoltre, si consideri memcached o alcune caratteristiche che si trovano in XCache.

Answer 3

Sembra che si sa quali sono i valori id 500 sono, quindi perché non fare qualcosa di simile:

// Assuming you have already validated that this array contains only integers
// so there is not risk of SQl injection

$ids = join(',' $arrayOfIds);

$sql = "SELECT `foo`, `bar` FROM `users` WHERE `id` IN ($ids)";