MySQL源码学习:关于慢查询日志中的Rows_examined=0
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了MySQL源码学习:关于慢查询日志中的Rows_examined=0,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含1602字,纯文字阅读大概需要3分钟。
内容图文
在说明这个问题之前,我们先指出两个相关背景:1、MySQL的临时表,都是MyISAM的。2、MyISAM表中的记录总数是额外存储的,count(*)
最近在一个项目中DBA同学问了一个问题:为什么很多慢查询日志中显示 Rows_examined : 0?
需要说明的是, 这类慢查询语句都是类似 select count(*) from (…)t;
在说明这个问题之前,我们先指出两个相关背景:
1、MySQL的临时表,都是MyISAM的。
2、MyISAM表中的记录总数是额外存储的,count(*)的时候不需要遍历数据。
3、把count(*)转换为取一个const值这件事情,是在优化(optimize)阶段作的。
问题分析:
这个值对应于代码中的examined_row_count,用于统计每次执行过程中实际扫描的记录数。
正常的流程:
查询执行过程中,每个子查询的信息都在curr_join,其中curr_join->examined_rows在每次扫一行的时候++.子查询完成后,curr_join->examined_rows累积到examined_row_count中。
哪里清0的?
我们上面这个语句,from内的子查询,curr_join->examined_rows是正常的,但在外部计算count的时候,上面提到的优化结果认为这个阶段是不需要扫描表的,把thd->examined_row_count给置0了。罪魁代码在JOIN::exec()中。
从代码中的注释来看,似乎是一个没有考虑细致的地方,待求证。
改进分析:
纵然有很多理由,在慢查询日志中显示的0还是不友好的,可以理解为是一个bug。
实际上从上面的分析可知,如果是复合查询中的一个环节,尤其不是第一个环节,此处清0会使显示结果出错。从当前的thd信息中可以判断出是否使用了子查询,简单一点的修改,,根据thd.derived_tables信息来确定是否清0。
实际上每次执行开始之前的这个值是被reset过的,有理由怀疑这个地方实际上可以直接删除这句话。这个比较激进,要求证一下。
简单验证:
加了thd.derived_tables判断后,
方便调试起见,把所有的查询都打到slow_log了。
内容总结
以上是互联网集市为您收集整理的MySQL源码学习:关于慢查询日志中的Rows_examined=0全部内容,希望文章能够帮你解决MySQL源码学习:关于慢查询日志中的Rows_examined=0所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。