这是MySQL SQL优化的第三篇。
公司某个业务系统频繁抛出问题SQL,我们对此类SQL做了基本面统计:

此类SQL近期共执行了12次,最长一次花费480秒,最短286秒

t1表的rows有90多万,始终会扫描这么多不需要的数据
这是由于MySQL查询优化器在处理相关子查询方面存在局限性
MySQL总是会将相关的外层表压到子查询中,它认为这可以更高效地查找数据行。
这就意味着MySQL先选择对外层表进行全表扫描,然后根据相关字段一个一个执行子查询,
如果是个小表,情况可能还不会引起我们注意,但是如果外层表示一个非常大的表,那么这个查询的性能会非常槽糕,
很不幸,我们的场景刚好应了后者
我们优化后的执行效果:

Good Luck!
本文针对公司业务系统中出现的问题SQL进行了分析与优化。通过对特定SQL的执行情况进行统计,发现其执行时间过长的原因在于MySQL查询优化器对于相关子查询处理不当,导致全表扫描大量不必要的数据。经过优化后,显著提升了查询效率。
6325

被折叠的 条评论
为什么被折叠?



