查詢在一些較新的 MySQL 版本中執行很長時間

我在 MySQL 5.0.15 上創建了一個數據庫。我有一個查詢，當我在這個 MySQL 版本上執行這個查詢時，我得到了 0.9 秒的執行時間。當我將此數據庫導入另一個具有相同硬體的 MySQL 伺服器並執行相同的查詢時，我得到了超過 120 秒，有時 MySQL 會掛起。

5.0 和 5.1 或 5.5 有什麼區別？我已經測試了 5.1 和 5.5 版本。

是否有可能在較新的版本中查詢需要更長的時間（例如 mysql 結構更改）？

對不起，我不能把這個查詢放在這裡，但查詢是這樣的：

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 

• 我有 4 個連接。
• 該表是innodb。
• 有 100000 條記錄

結果是 100 行和 50 列。

解釋結果是

顯示變數，如 ‘innodb%’ 結果

剛開始，新版本的 MySQL 實際上提高了 innodb 的性能（尤其是 5.5）。如果您要執行 InnoDB，我強烈建議您更新到此版本。

您可以使用一種方法來找出為什麼需要這麼長時間的原因是使用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)

這應該讓您知道它掛在哪裡。從您的解釋輸出中，您應該嘗試在第二個和第三個表上獲取一些索引，而不是進行全表掃描。但是如果沒有 DDL 或實際的連接列，我沒有比研究索引策略更好的建議了。

引用自：https://dba.stackexchange.com/questions/6526