迁移到 mysql 5.7 后查询速度极慢

Question

我有一个包含 InnoDB 表的 MySQL 数据库，汇总了超过 10 10 GB 的数据，我想将这些数据从 MySQL 5.5 迁移到 MySQL 5.7。 我有一个看起来有点像的查询：

SELECT dates.date, count(mySub2.myColumn1), sum(mySub2.myColumn2)
FROM (
    SELECT date
    FROM dates -- just a table containing all possible dates next 5 years
    WHERE date BETWEEN '2016-06-01' AND '2016-09-03'
) AS dates
LEFT JOIN (
    SELECT o.id, time_start, time_end
    FROM order AS o
    INNER JOIN order_items AS oi on oi.order_id = o.id
    WHERE time_start BETWEEN '2016-06-01' AND '2016-09-03'
) AS mySub1 ON dates.date >= mySub1.time_start AND dates.date < mySub1.time_end
LEFT JOIN (
    SELECT o.id, time_start, time_end
    FROM order AS o
    INNER JOIN order_items AS oi on oi.order_id = o.id
    WHERE o.shop_id = 50 AND time_start BETWEEN '2016-06-01' AND '2016-09-03'
) AS mySub2 ON dates.date >= mySub2.time_start AND dates.date < mySub2.time_end
GROUP BY dates.date;

我的问题是这个查询在 MySQL 5.5 中执行得很快，但在 MySQL 5.7 中执行得非常慢。

在 MySQL 5.5 中，它首先需要超过 1 秒，并且每次重复执行 < 0.001 秒而无需重新启动 MySQL。
在 MySQL 5.7 中，它首先需要 11.5 秒，每次重复执行需要 1.4 秒，而无需重新启动 MySQL。
我添加到查询中的 LEFT JOIN 越多，查询在 MySQL 5.7 中变得越慢。

现在，这两个实例都运行在同一台机器上，在同一硬盘驱动器上，并且具有相同的 my.ini 设置。 所以它不是硬件。
不过，执行计划确实有所不同，我不知道该怎么做。

这是 MySQL 5.5 上的 EXPLAIN EXTENDED：

| id | select_type | table      | type  | possible_keys | key         | key_len | ref       | rows  | filtered | extra                           |
|----|-------------|------------|-------|---------------|-------------|---------|-----------|-------|----------|---------------------------------|
| 1  | PRIMARY     | dates      | ALL   |               |             |         |           | 95    | 100.00   | Using temporary; Using filesort |
| 1  | PRIMARY     | <derived2> | ALL   |               |             |         |           | 281   | 100.00   | ''                              |
| 1  | PRIMARY     | <derived3> | ALL   |               |             |         |           | 100   | 100.00   | ''                              |
| 3  | DERIVED     | o          | ref   | xxxxxx        | shop_id_fk  | 4       | ''        | 1736  | 100.00   | ''                              |
| 3  | DERIVED     | oc         | ref   | xxxxx         | order_id_fk | 4       | myDb.o.id | 1     | 100.00   | Using index                     |
| 2  | DERIVED     | o          | range | xxxx          | date_start  | 3       |           | 17938 | 100.00   | Using where                     |
| 2  | DERIVED     | oc         | ref   | xxx           | order_id_fk | 4       | myDb.o.id | 1     | 100.00   | Using where                     |

这是 MySQL 5.7 上的 EXPLAIN EXTENDED：

| id | select_type | table | type   | possible_keys | key         | key_len | ref              | rows | filtered | extra          |
|----|-------------|-------|--------|---------------|-------------|---------|------------------|------|----------|----------------|
| 1  | SIMPLE      | dates | ALL    |               |             |         |                  | 95   | 100.00   | Using filesort |
| 1  | SIMPLE      | oi    | ref    | xxxxxx        | order_id_fk | 4       | const            | 228  | 100.00   |                |
| 1  | SIMPLE      | o     | eq_ref | xxxxx         | PRIMARY     | 4       | myDb.oi.order_id | 1    | 100.00   | Using where    |
| 1  | SIMPLE      | o     | ref    | xxxx          | shop_id_fk  | 4       | const            | 65   | 100.00   | Using where    |
| 1  | SIMPLE      | oi    | ref    | xxx           | order_id_fk | 4       | myDb.o.id        | 1    | 100.00   | Using where    |

我想了解为什么 MySQL 处理相同的查询有很大不同，以及如何调整 MySQL 5.7 以使其更快？
我不是在寻求帮助以更快地重写查询，因为这是我自己已经在做的事情。

Answer 1

从评论中可以看出，@wchiquito 建议查看optimizer_switch 。 在这里，我发现可以将开关derived_merge设置为关闭，以修复这个新的，在这种特定情况下不受欢迎的行为。

set session optimizer_switch='derived_merge=off'; 解决问题。
（这也可以通过set global ...或放在 my.cnf / my.ini 中完成）

Answer 2

构建和维护“汇总表”将使此查询的运行速度甚至比 1 秒快得多。

这样的表可能包括shop_id 、 date和一些计数。

更多关于汇总表。

Answer 3

迁移到 mysql 5.7 后，我也遇到了查询执行缓慢的问题，就我而言，甚至将 session optimizer_switch 设置为“derived_merge=off”； 没有帮助。

然后，我点击了这个链接： https : //www.saotn.org/mysql-innodb-performance-improvement/并且查询的速度变得正常了。

具体来说，我的更改只是在 my.ini 中设置这四个参数，如链接中所述：

innodb_buffer_pool_size

innodb_buffer_pool_instances

innodb_write_io_threads

innodb_read_io_threads