vlambda博客
学习文章列表

MYSQL 8 VS MYSQL 5.7 在复杂查询中 到底好了多少

MySQL 8 最终是要大面积替换MYSQL5.7 , 之前的文字可能给人感觉MYSQL 8 还不如 MYSQL 5.7 ,实际上不然,任何东西新的一定有问题,解决解决就好了,在复杂查询这块 MYSQL 5.7 的确是和MYSQL 8 已经有了分别,对于开发人员撰写SQL 有什么帮助我们可以看看下面的一些例子。

下面是MYSQL 8 和 MYSQL 5.7 在一个稍微复杂查询的执行计划

MYSQL 8 VS MYSQL 5.7 在复杂查询中 到底好了多少

MYSQL 8 VS MYSQL 5.7 在复杂查询中 到底好了多少

对比上面的图,一样的语句,一样的数据库,一样的表,一样的数据行数和内容,mysql 8 由于各种优化,去掉了 using firesort,并且由于这一项,节省了近 20秒

MYSQL 8 VS MYSQL 5.7 在复杂查询中 到底好了多少MYSQL 8 VS MYSQL 5.7 在复杂查询中 到底好了多少


下面还有相关的例子,还是出了MYSQL 版本不一致,包括硬件其他的都一样的情况下,mysql 8 比 mysql 5.7 要快 4倍 34秒与128秒的区别,不同的还是那个 filesort

mysql 8.018

MYSQL 8 VS MYSQL 5.7 在复杂查询中 到底好了多少

MYSQL 8 VS MYSQL 5.7 在复杂查询中 到底好了多少

mysql 5.7.23

MYSQL 8 VS MYSQL 5.7 在复杂查询中 到底好了多少

MYSQL 8 VS MYSQL 5.7 在复杂查询中 到底好了多少


通过这两个例子可以看到,在使用GROUP BY 这样的语句,在没有特殊优化的情况下,,MYSQL 8 不在使用 FILESORT 排序后,速度有了大幅度的提升,这说明在没有优化的情况下,MYSQL 8 对于排序和GROUP BY 这样的查询时有利的,并且随着提取的数据越多,则越快,这对 DEVELOPER 是一个好消息。


MYSQL 8

MYSQL 8 VS MYSQL 5.7 在复杂查询中 到底好了多少

MYSQL 8 VS MYSQL 5.7 在复杂查询中 到底好了多少

MySQL 5.7

MYSQL 8 VS MYSQL 5.7 在复杂查询中 到底好了多少

MYSQL 8 VS MYSQL 5.7 在复杂查询中 到底好了多少

上面的测试中,如果不带有Join salaries 的情况下,实际情况是MYSQL 5,7 还会稍微的好一些,MYSQL 8 会将not exists not in 里面的子查询先 Materialized  一下,相对来说,如果 not exists not in 里面的要排除的数据越少越好,条件越精准越好,这样MYSQL 8 的 antijoin 的功能就会能帮助查询更有效的排除数据。这里在所有都一样的情况下,MYSQL 8 比 MYSQL 5.7 快 2倍的时间。


当然也有一些差强人意的,下面的两个查询时间上基本相同,可能需要更多的将语句重新格式的时间,mysql 8 还慢了0.2秒

MYSQL 8 

MYSQL 8 VS MYSQL 5.7 在复杂查询中 到底好了多少


MYSQL 8 VS MYSQL 5.7 在复杂查询中 到底好了多少


总体来说mysql 在hash join , 免filesort 的新功能对大部分查询语句是有帮助的,但实际上在测试中有些简单的语句,MYSQL 8 并不能占据什么便宜,或者说还可能会比MYSQL 5.7 慢了“一眨眼” 的功夫。


最后总结一下,

如果当前MYSQL 5.X 中运行的系统逻辑并不复杂,执行的语句都是简单的,那换了MYSQL 8 可能并不能得到什么好处,甚至会“挨骂”。 

而如果本身就是从其他数据库迁移过来的系统,语句写的比较“水”,则更换MYSQL 8 会让一些SQL 跑的好看一些, 期待MYSQL 也能并行查询。


MYSQL 8 VS MYSQL 5.7 在复杂查询中 到底好了多少