La consulta corre mucho tiempo en algunas versiones más nuevas de MySQL

Question

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%'

Answer 1

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.

Answer 2

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.

• OPCIÓN 1 : Use archivos de espacio de tabla separados para innoDB, separando datos e páginas de índice de IBDATA1

• 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 4: Sintonizar correctamente las opciones de innodb

• Opción 5: Tamaño su grupo de búfer innodb para que sea lo suficientemente grande como para contener todos los datos, o el 75% de la RAM instalada, lo que sea más pequeño.

• 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.