升级MySQL5.7，开发不得不注意的坑(4)

日期：2020-06-02 栏目：程序人生浏览：次

这里，对之前提到的，MySQL 5.7中不再兼容的实现方式也做了个测试，在没有任何索引的情况下，其稳定在0.7s（性能并不弱，怪不得有人使用），而同等情况下，方法1稳定在0.5s（哈，MySQL 5.6竟然比8.0还快）。但与方法1不同的是，其无法通过索引进行优化。

从执行计划上看，

方法1，先将group by的结果放到临时表中，然后再将该临时表作为驱动表，来和dept_emp表进行关联查询。驱动表小（只有9条记录），关联列又有索引，无怪乎，结果能秒出。

方法2，两表关联。其犯了SQL优化中的两个大忌。

1. 驱动表太大，其有331603条记录。

2. 被驱动表虽然也有索引，但从执行计划上看，其只使用了复合索引 (dept_no, from_date)中的dept_no，而dept_no的选择率又太低，毕竟只有9个部门。

方法3，先把分析的结果放到一个临时表中，然后再对该临时表进行处理。其进行了两次全表扫描，一次是针对dept_emp表，一次是针对临时表。

所以，对于分组求最值的需求，建议使用方法1，其不仅符合SQL规范，查询性能上也是最好的，尤其是在联合索引的情况下。

PS：

经大神指点，对之前提到的，MySQL 5.7中不再兼容的实现方式，实际可以通过调整optimizer_switch来加以规避

set optimizer_switch='derived_merge=off';

derived_merge是MySQL 5.7引入的，其会试图将Derived Table（派生表，from后面的子查询），视图引用，公用表表达式（Common table expressions）与外层查询进行合并。如，

SELECT *
FROM t1 JOIN (SELECT t2.f1 FROM t2) AS derived_t2
ON t1.f2=derived_t2.f1
WHERE t1.f1 > 0;

改写为

SELECT *
FROM t1 JOIN (SELECT DISTINCT f1 FROM t2) AS derived_t2
ON t1.f1=derived_t2.f1;