MySQL查询优化技术的一点儿问答

最新推荐文章于 2024-05-29 17:57:31 发布

原创最新推荐文章于 2024-05-29 17:57:31 发布 · 438 阅读

0 ·

CC 4.0 BY-SA版权

数据库专栏收录该内容

289 篇文章

订阅专栏

本文解析了MySQL中EXPLAIN工具的局限性与应用技巧，包括它无法揭示触发器、存储过程等影响；说明了数据缓存区如何影响查询执行计划；介绍了如何使用optimizer_trace功能来观察MySQL的优化工作；澄清了Select table optimized away的真实含义。

1 EXPLAIN不会告诉你关于触发器、存储过程的信息或用户自定义函数对查询的影响情况，---是

2 同时，EXPLAIN不考虑各种Cache，--你觉得需要考虑哪些cache？在MySQL5.7.5版本之后，MySQL的优化器可以聪明地考虑“数据缓存区了”，在这之后的版本，将继续完善这一功能。其实，缓存中影响查询执行计划形成的，主要就是数据缓存区

3 并且EXPLAIN不能显示MySQL在执行查询时所作的优化工作---可以用“optimizer_trace”功能达到你的目的。参见《数据库查询优化器的艺术》附录D2节. 或查阅MySQL官方文档

4 最后，EXPALIN只能解释SELECT操作，其他操作要重写为SELECT后查看执行计划---MySQLEXPLAIN是支持DML的，不光是DQL。

5 Extra有时候会显示“Select tables optimized away”，意思是没有更好的可优化的了。官方解释For explains on simple count queries (i.e. explain select count(*) from people) the extra section will read "Select tables optimized away." This is due to the fact that MySQL can read the result directly from the table internals and therefore does not need to perform the select.

---MySQL对于“Select tables optimized away”的含义, 不是"没有更好的可优化的了", 官方解释中关键的地方在于:

MySQL can read the result directly

所以,合理的解释是: 1 数据已经在内存中可以直接读取; 2 数据可以被认为是一个经计算后的结果,如函数或表达式的值; 3 一旦查询的结果被优化器"预判"可以不经执行就可以得到结果,所以才有"not need to perform the select".

这是不是表明MySQL的优化器"很聪明呢"?