La consulta corre mucho tiempo en algunas versiones más nuevas de MySQL
Pregunta
He creado una base de datos en MySQL 5.0.15. Tengo una consulta y cuando ejecuto esta consulta en esta versión MySQL, obtengo un tiempo de ejecución de 0.9 s. Cuando importo esta base de datos a otro servidor MySQL con el mismo hardware y ejecuto la misma consulta, obtengo más de 120s y, a veces, MySQL cuelga.
¿Cuál es la diferencia entre 5.0 y 5.1 o 5.5? He probado versiones 5.1 y 5.5.
¿Es posible que una consulta lleva más tiempo en una versión más nueva (algo como el cambio de estructura mySQL)?
Lo siento, pero no puedo poner esta consulta aquí, pero la consulta es como:
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
Tengo 4 uniones.
La mesa es innodb.
Hay 100000 registros
El resultado son 100 filas y 50 columnas.
Explicar el resultado es
Mostrar variables como el resultado 'innodb%'
Solución
Justo al lado, las versiones más nuevas de MySQL en realidad mejoran el rendimiento de innodb (especialmente 5.5). Recomiendo encarecidamente actualizarse a esta versión si va a ejecutar innodb.
Un método que podría usar para buscar por qué tarda tanto más es Perfiles mysql
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)
Esto debería darle una indicación de dónde está colgando. Desde su salida de explicación, debe intentar obtener algo de indexación en la segunda y tercera tablas en lugar de hacer escaneos de mesa completos. Pero sin DDL o las columnas de unión reales, no puedo sugerir nada mejor que investigar estrategias de indexación.
Otros consejos
El uso de MySQL 5.5 listo para usar sin la configuración adecuada es Como obtener un Lamborghini y esperar un rendimiento de primer nivel en un galón de gasolina regular (87 octano).
Deberías esperar mejor rendimiento con gasolina de alto octanaje en un Lamborghini.
Como con cualquier producto de base de datos, solo es tan mejorado como lo configura. Al igual que Spiderman dijo (8:36 - 8:40): "Con gran poder, también siempre debe haber una gran responsabilidad".
Para obtener un mejor rendimiento de MySQL 5.5, debe configurar honestamente ciertas cosas.
OPCION 2 : Configurar opciones que involucren más CPU
Opción 3: Aumentar el número de hilos dedicados para lecturas y escrituras
Opción 6: Use O_Direct para innodb Flushing
Opción 7: Use un servidor DB dedicado, aparte de LAMP, WAMP, XAMPP, MUNIN y Software como estos.