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 ...?
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!). –
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. –