Query viene eseguita molto tempo in alcune versioni di MySQL più recenti
Domanda
Ho creato una banca dati su MySQL 5.0.15. Ho una domanda, e quando ho eseguito questa ricerca questa versione di MySQL, ottengo 0,9 s fase di esecuzione. Quando importo questo database a un altro server MySQL con lo stesso hardware e esegue la stessa query supero 120s e si blocca a volte MySQL.
Qual è la differenza tra 5.0 e 5.1 o 5.5? Ho testato 5.1 e 5.5 versioni.
E 'possibile interrogare un richiede più tempo in una versione più recente (si parla di cambiamento della struttura mysql)?
Ci dispiace ma non posso mettere questa domanda qui, ma la domanda è come:
SELECT fl_passenger_ticket. *,
fl_aganc.name AS agancname,
fl_pnr.remark AS remark,
fl_pnr.reservetime AS reservetime,
fl_pnr.cancelpnr,
fl_flight_date.fromcity AS fromcity,
fl_flight_date.tocity AS tocity,
fl_flight_date.flightdate AS flightdate,
fl_flightdate_capacity.adultper AS adultper,
fl_flightdate_capacity.childper AS childper,
fl_flightdate_capacity.infantper AS infantper,
fl_flightdate_capacity.cancel AS cancelsegment,
fl_flightdate_capacity.tax1adultpric,
fl_flightdate_capacity.tax1childpric,
fl_flightdate_capacity.tax1infantpric,
fl_flightdate_capacity.tax2adultpric,
fl_flightdate_capacity.tax2childpric,
fl_flightdate_capacity.tax2infantpric,
( fl_flightdate_capacity.tax3adultpric +
fl_flightdate_capacity.tax4adultpric +
fl_flightdate_capacity.tax5adultpric ) AS taxxtadultpric,
( fl_flightdate_capacity.tax3childpric +
fl_flightdate_capacity.tax4childpric +
fl_flightdate_capacity.tax5childpric ) AS taxxtchildpric,
( fl_flightdate_capacity.tax3infantpric +
fl_flightdate_capacity.tax4infantpric
+
fl_flightdate_capacity.tax5infantpric ) AS taxxtinfantpric
FROM fl_passenger_ticket
INNER JOIN fl_pnr
ON ( fl_passenger_ticket.pnrid = fl_pnr.pnrid )
INNER JOIN fl_aganc
ON ( fl_pnr.agancid = fl_aganc.agancid )
LEFT JOIN fl_flightdate_capacity
ON ( fl_pnr.pnrid = fl_flightdate_capacity.pnrid )
LEFT JOIN fl_flight_date
ON ( fl_flightdate_capacity.flightdateid = fl_flight_date.flightdateid
)
WHERE fl_passenger_ticket.ticketnumber <> ''
AND fl_passenger_ticket.pnrid <> 0
AND fl_pnr.agancid = 60
AND fl_flightdate_capacity.aganccharterid = 0
AND fl_flightdate_capacity.cancel IN ( 0, 1 )
AND fl_pnr.reservetime >= '2011/09/01 00:00:00'
AND fl_pnr.reservetime <= '2011/09/19 23:59:00'
ORDER BY fl_passenger_ticket.rowid,
fl_pnr.reservetime
-
Ho 4 join.
-
Il tavolo è InnoDB.
-
Non ci sono 100000 record
Il risultato è 100 righe e 50 colonne.
SPIEGARE risultato è
Mostra variabili come 'InnoDB%' risultato
Soluzione
Appena fuori del blocco, le versioni più recenti di MySQL effettivamente migliorare le prestazioni InnoDB (in particolare 5.5). Mi raccomando l'aggiornamento a questa versione, se si sta andando a correre InnoDB.
Un metodo si potrebbe usare per dare la caccia perché sta prendendo così tanto più sta usando MySQL Profili
mysql> SET PROFILING=1;
mysql> SHOW TABLES;
mysql> SELECT * FROM foo;
mysql> SET PROFILING=0;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW PROFILES;
+----------+------------+-------------------+
| Query_ID | Duration | Query |
+----------+------------+-------------------+
| 1 | 0.09270400 | SHOW TABLES |
| 2 | 0.00026400 | SELECT * FROM foo |
+----------+------------+-------------------+
2 rows in set (0.05 sec)
mysql> SHOW PROFILE FOR QUERY 2;
+----------------------+----------+
| Status | Duration |
+----------------------+----------+
| starting | 0.000053 |
| checking permissions | 0.000009 |
| Opening tables | 0.000032 |
| System lock | 0.000010 |
| init | 0.000028 |
| optimizing | 0.000003 |
| statistics | 0.000012 |
| preparing | 0.000008 |
| executing | 0.000003 |
| Sending data | 0.000068 |
| end | 0.000004 |
| query end | 0.000007 |
| closing tables | 0.000008 |
| freeing items | 0.000013 |
| logging slow query | 0.000003 |
| cleaning up | 0.000003 |
+----------------------+----------+
16 rows in set (0.04 sec)
Questo dovrebbe dare un indicazione di dove è appeso. Dalla vostra uscita spiegare, si dovrebbe cercare di ottenere qualche indicizzazione sulla seconda e terza tabella invece di fare scansione completa della tabella. Ma senza DDL o l'attuale uniscono le colonne, non posso suggerire qualcosa di meglio che le strategie di indicizzazione di ricerca.
Altri suggerimenti
Utilizzando MySQL 5.5 out-of-the-box, senza una corretta configurazione è come ottenere un Lamborghini e in attesa di prestazioni topnotch su un gallone di benzina normale (87 ottani).
Si deve aspettare migliori prestazioni ad alto numero di ottano della benzina in una Lamborghini .
Come con qualsiasi prodotto di database, è solo come prestazioni rafforzata per quanto effettivamente configurarlo. Proprio come Spiderman detto (8:36-08:40): "Da un grande potere, ci deve essere anche SEMPRE grandi responsabilità" .
Per ottenere prestazioni migliori di MySQL 5.5, è necessario configurare onestamente certe cose.
-
OPZIONE 1: Usa separano file di tablespace per InnoDB, che separano i dati e le pagine di indice da ibdata1
-
OPZIONE 3: Aumentare il numero di thread dedicati per le letture e scritture
-
OPZIONE 4: correttamente sintonia Opzioni InnoDB
-
OPZIONE 6: Usa O_DIRECT per InnoDB Flushing
-
OPZIONE 7:. Usare un DB server dedicato, a parte LAMP, WAMP, XAMPP, Munin, e software come questi