本文分析了MySQL在创建数据表和执行查询时出现速度慢的问题，通过(optimizer trace)工具揭示了MySQL优化器在处理SQL时的决策过程。发现MySQL 5.7在处理information_schema.columns这类元数据表时，由于行数估算错误导致选择了低效的执行计划。在MySQL 8.0中，由于数据字典的改进，对元数据表的查询优化有所提升，建议在使用时注意执行计划并考虑使用hint进行调整。
问题
在 26 问中，我们看到了如下 SQL 在 MySQL 5.7 中跑得很慢：
我们还分析了执行计划改写后的 SQL，通过猜测，增加了 hint 来解决问题：
这一期，我们通过工具来分析一下：MySQL 为什么会使用一个低效的执行计划，以致于我们不得已用 hint 来调优 SQL？
实验
我们接着使用 26 问中的环境，使用 optimizer trace 工具，观察 MySQL 对 SQL 的优化处理过程。
我们先调大 optimizer trace 的内存容量(否则 trace 的输出会被截断)，然后开启了optimizer trace 功能。
跑完 SQL 后，可以在 INFORMATION_SCHEMA.OPTIMIZER_TRACE 看到 SQL 的优化处
最低0.47元/天 解锁文章
441
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
