2009-04-25 14 views
48

Sto aiutando a mantenere un programma essenzialmente un front-end di sola lettura per un grande e complicato database MySQL: il programma costruisce query SELECT ad-hoc dall'input degli utenti, invia le query al DB, ottiene il risultati, li post-li elabora e li visualizza piacevolmente all'utente.Come utilizzare EXPLAIN per * prevedere * le prestazioni di una query MySQL?

Vorrei aggiungere qualche forma di previsione ragionevole/euristica per le prestazioni previste della query costruita - a volte gli utenti fanno inavvertitamente query che inevitabilmente impiegheranno molto tempo (perché restituiranno serie di risultati enormi, o perché stanno "andando contro" nel modo in cui il DB è indicizzato) e mi piacerebbe poter mostrare all'utente alcune informazioni "un po 'affidabili"/indovinare quanto tempo impiegherà la query. Non deve essere perfetto, purché non diventi così male e frequentemente fuori di testa con la realtà da provocare un effetto "lupo-lupo" in cui gli utenti imparano a ignorarlo ;-) Basandosi su queste informazioni, l'utente potrebbe decidere di andare a prendere un caffè (se la stima è di 5-10 minuti), andare a pranzo (se è 30-60 minuti), uccidere la query e provare qualcos'altro invece (forse limiti più stretti sulle informazioni che stanno richiedendo), ecc, ecc

io non sono molto familiarità con MySQL di spiegare dichiarazione - vedo un sacco di informazioni in giro su come utilizzarlo per ottimizzare una query o lo schema di un DB, indicizzazione, ecc, ma non molto su come usarlo per il mio scopo più limitato - semplicemente fare una previsione, prendendo il DB come dato (ovviamente se le previsioni sono abbastanza affidabili potrei eventualmente passare a usarle anche per scegliere tra forme alternative a la query potrebbe richiedere, ma, questo è per il futuro: per ora, sarei molto felice solo per mostrare agli utenti le ipotesi di rendimento per gli scopi sopra menzionati).

Eventuali puntatori ...?

risposta

20

EXPLAIN non ti darà alcuna indicazione di quanto tempo richiederà una query. Nella migliore delle ipotesi potresti usarlo per indovinare quale delle due query potrebbe essere più veloce, ma a meno che uno di essi non sia ovviamente scritto male, anche quello sarà molto difficile.

Si dovrebbe anche essere consapevoli del fatto che se si utilizzano le sottoquery, anche l'esecuzione di EXPLAIN può essere lento (quasi lento come la query stessa in alcuni casi).

Per quanto ne so, MySQL non fornisce alcun modo per stimare il tempo necessario per eseguire una query. Potresti registrare il tempo impiegato da ogni query per eseguire, quindi creare una stima basata sulla cronologia delle query simili passate?

+1

Non generiamo sub-query in questo momento in modo che bit non dovrebbe essere un problema. Ma grazie comunque per il puntatore - e la notizia che non c'è un buon modo per stimare il costo di una query (cattive notizie, ma, meglio imparare prima di passare un tempo illimitato a rincorrere una chimera!). –

+10

EXPLAIN è estremamente utile. Non sono sicuro del motivo per cui questa è la "risposta". Scopri la cardinalità: maggiore è il numero di righe, maggiore è la ricerca da eseguire. Inoltre, mostra quali, se del caso, vengono utilizzati indici. Questo è fondamentale per le prestazioni SELECT. Per quanto riguarda le sottoquery, è molto raro che siano effettivamente necessarie - dovrebbero essere refactored, quando possibile, per motivi di chiarezza. –

11

Penso che se si vuole avere una possibilità di costruire qualcosa di abbastanza affidabile da ciò, ciò che si dovrebbe fare è costruire un modello statistico di dimensioni di tabella e componenti di risultato SCOPRI dettagliati correlati con i tempi di elaborazione della query. Cercando di costruire un predittore di tempo di esecuzione della query basato su pensando a il contenuto di una SPIEGA sta andando a spendere troppo tempo dando risultati imbarazzanti poveri prima che venga raffinato a una vaga utilità.

2

MySQL EXPLAIN ha una colonna denominata Key. Se c'è qualcosa in questa colonna, questa è un'ottima indicazione, significa che la query utilizzerà un indice.

Le query che utilizzano gli indici sono generalmente sicure da utilizzare poiché sono state probabilmente pensate dal progettista del database quando ha progettato il database.

Tuttavia

C'è un altro campo chiamato Extra. Questo campo contiene talvolta il testo using_filesort.

Questo è molto molto male. Ciò significa letteralmente che MySQL sa che la query avrà un set di risultati più grande della memoria disponibile e quindi inizierà a scambiare i dati su disco per ordinarli.

Conclusione

Invece di cercare di prevedere il tempo una query richiede, semplicemente un'occhiata a questi due indicatori. Se una query è using_filesort, negare l'utente. E a seconda di quanto vuoi essere severo, se la query non usa alcuna chiave, dovresti anche negarla.

Leggi di più riguardo il gruppo di risultati della MySQL EXPLAIN statement

Problemi correlati