2012-04-30 13 views
5

come indica il titolo, nel mio database varie query vengono visualizzate nel registro delle query lente, ma quando le eseguo manualmente vengono eseguite 10 volte più velocemente.Le query lente di MYSQL nel "log delle query lente", ma le stesse query vengono eseguite molto rapidamente manualmente

ad esempio relativamente semplice query di selezione con diversi ordini da params spesso richiede fino a 100 secondi di registro (sì tabella è molto grande) ... ma quando l'eseguo io sullo stesso DB ci vogliono 2 secondi o giù di lì .

Ho esaminato le prestazioni del server e non sembra esserci un rallentamento o un collo di bottiglia particolari al momento, né ci sono molte query che richiedono molto tempo in quel periodo ma solo quella.

come posso iniziare ad analizzare un tale problema?

grazie per l'aiuto

+0

mi piacerebbe iniziare con la pubblicazione di uno di tali interrogazioni qui per l'assistenza nella analizzandolo insieme ad un "spiegano SELECT ..." per mostrare ciò che il motore di vuole fare per il suo percorso di esecuzione di query. – DRapp

+0

Di solito se una query impiega 1 o più secondi, viene catturata dal log delle query lente. 2 secondi è sicuramente più alto di 1 secondo. –

+0

Wild guess: la query è veloce quando la esegui manualmente perché i risultati sono stati memorizzati nella cache durante la prima esecuzione della query. Per controllarlo, cancella tutte le cache e poi prova di nuovo la stessa query: dovrebbero impiegare 100 secondi. – nikhil500

risposta

5

Il sistema può essere stato più occupato quando la query incriminata è entrato nel registro lento.

Il registro lenta può indicare che gli indici non sono pienamente utilizzate se il rows_examined è più grande del set di risultati. Pertanto, il tempo di esecuzione dovrebbe essere considerato come un indizio del fatto che una query ha un problema, ma lo standard rows_examined ti darà una risposta definitiva.

tempo di query è una misura scarso rendimento su un server con carico elevato, perché ogni query può essere lenta su un server occupato. Dovresti usare EXPLAIN e SHOW PROFILE per profilare le tue query e migliorarle in modo che non sovraccarichino troppo il tuo server.

Uso SELECT SQL_NO_CACHE ... profilare query quindi i risultati non sono memorizzati nella cache di query, altrimenti esecuzioni successive della stessa query possono utilizzare la cache di query, inclinazione qualsiasi temporizzazione della query.

+0

per quanto riguarda la cache: quando ho eseguito la query manualmente (ancora sul server, non localmente, sullo stesso DB) ho cambiato l'ordine di alcune delle condizioni, quindi non sarà in grado di abbinare il risultato alla query eseguita in precedenza. Ho eseguito spiegazioni e mostra che utilizza alcuni indici, ma non sono sicuro che siano corretti. nella lista "possibili indici" c'erano molti altri indici che non erano usati. –

+0

ho anche notato che il numero di righe scansionate supera di molto il numero di righe effettivamente recuperate. infatti la dichiarazione stessa ha LIMIT 50 su di esso, e righe analizzate è di circa 3000. i miei pensieri erano che è a causa di ORDER BY nella dichiarazione, che la mia comprensione fetchs tutte le righe (anche se non c'è limite alla query) e solo dopo che l'ordine da esso restituisce 50. è corretto? –

+0

@MikiBergin, se la clausola ORDER BY può essere servita dall'indice, allora non dovrà necessariamente recuperare tutte le righe. Ci sono alcuni avvertimenti, ma è troppo da discutere qui. Raccomando che se hai bisogno di aiuto per ottimizzare una query specifica, pubblica una domanda a parte, completa con l'intera query, lo schema pertinente e i risultati EXPLAIN e SHOW PROFILE. –

Problemi correlati