Requête est exécutée depuis longtemps dans certaines versions de MySQL

dba.stackexchange https://dba.stackexchange.com/questions/6526

Question

J'ai créé une base de données sur MySQL 5.0.15. J'ai une requête et quand je lance cette requête sur cette version MySQL, je reçois 0,9 de temps d'exécution. Quand j'importer cette base de données à un autre serveur MySQL avec la même matériel et exécuter la même requête que je reçois sur 120s et se fige parfois MySQL.

Quelle est la différence entre 5,0 et 5,1 ou 5,5? Je l'ai testé 5.1 et 5.5 versions.

Est-il possible une requête prend plus de temps dans une version plus récente (quelque chose comme le changement de la structure mysql)?

Désolé, mais je ne peux pas mettre cette requête, mais la requête est comme: 

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

  • J'ai 4 Assemble.

  • Le tableau est InnoDB.

  • Il y a 100000 enregistrements

Le résultat est de 100 lignes et de 50 colonnes.

EXPLIQUEZ résultat est entrer image description ici

Afficher les variables comme 'InnoDB%' résultat

entrer image description ici

Était-ce utile?

La solution

Juste à côté de la chauve-souris, les nouvelles versions de MySQL améliorer réellement les performances InnoDB (en particulier 5.5). Je recommande fortement la mise à jour de cette version si vous allez courir InnoDB.

Une méthode que vous pouvez utiliser pour traquer pourquoi il prend est beaucoup plus en utilisant MySQL profils 

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)

Cela devrait vous donner une indication de l'endroit où il est suspendu. De votre expliquer la sortie, vous devriez essayer d'obtenir une indexation sur les deuxième et troisième tables au lieu de faire des scans de table. Mais sans réelle ou DDL colonnes de jointure, je ne suggère rien de mieux que de stratégies d'indexation de recherche.

Autres conseils

Licencié sous: CC-BY-SA avec attribution
Non affilié à dba.stackexchange
scroll top