前言
这里主要是 探究一下 explain $sql 中各个 type
诸如 const, ref, range, index, all 的查询的影响, 以及一个初步的效率的判断
这里会调试源码来看一下 各个类型的查询 需要 lookUp 的记录
以及 相关的差异
测试表结构信息如下
CREATE TABLE `tz_test` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`field1` varchar(12) DEFAULT NULL,
PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=3333343 DEFAULT CHARSET=utf8
测试数据为序列 1 – 99
const 查询存在的记录
这里以主键查询来调试一下 这里的整个流程
select * from tz_test where id = 33;
这里是主键查询, 首先根据index获取所属分页, 然后在目标分页进行 pageDirectory 的二分查找
然后再根据用户记录 线性查找, 找到目标记录, 将 cursor 存储与 prebuilt->pcur->btr_cur->page_cur->rec
然后 后续的迭代是基于这个 记录开始迭代的
我们来看一下 ‘field33’ 记录附近的内存信息的一个剖析
下面的tuple->fields->data 记录的是比较的条件
row_search_mvcc 流程中 ”where id = 33” 条件的比较判断
比较的流程如下, 按照字段逐个比较
如果有一项比较出结果, 直接返回, 如果 所有的字段均匹配上响应 0
int 以及 一部分类型的比较方式如下, int 的比较如下 逐字节比较
其次使用 memcmp 比较两个字节序列
将 rec 复制到 mysql_rec[外部传入的 READ_RECORD 的 buf]
rec 和 mysql_rec 的相关
然后 记录往后迭代, 迭代到 field34 对应的记录 
然后下一次迭代, 继续进入这里的比较, 两者不相等, row_search_mvcc 执行结束
将结果输出给客户端的地方如下
当前查询是一个 const 查询计划, 只会返回 0条 或者 1条 记录
因此, 这里就直接 退出查询了, 没有查询记录的迭代
const 查询不存在的记录
在 optimize 的时候, 发现没有匹配到的记录, 这里 打上了一个标记
初始化的时候 const_table_map 初始化为 1
join_read_const_table 是根据主键条件去查询记录, 结果没有查询到 返回状态 -1
然后 这里 found_const_table_map 一直是 0, 和后面匹配不上
根据 index 去获取 page, 根据 pageDirectory, record 去比较之后找到的最近的记录
然后 这里根据 ”where id = 33333” 比较失败, 返回 DB_RECORD_NOT_FOUND
然后 外层对异常进行处理, 最终 join_read_const_table 拿到的状态为 -1
最终 const_table_map 和 found_const_table_map 匹配不上, 进而标记了 zero_result_cause
然后 外层执行查询的时候, 发现有 zero_result_cause, 直接仅仅响应了元数据回去
完
