前言
这里主要是 探究一下 explain $sql 中各个 type 

诸如 const, ref, range, index, all 的查询的影响, 以及一个初步的效率的判断 

这里会调试源码来看一下 各个类型的查询 需要 lookUp 的记录 

以及 相关的差异 

此系列文章建议从 mysql const 查询 开始看

 

测试表结构信息如下 

 
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

 

 

range 查询存在的记录

执行查询如下 “select * from tz_test where field1 > 'field33' and field1 < 'field37';”

 

optimize 的时候, 根据索引定位了 ”field33” 和 “field37” 的位置 

 

第一次查询是从索引 ‘field34’ -> 34 开始, 然后 row_search_idx_cond_check 来判断当前记录是否满足条件 

比较的方式是当前记录的给定的字段 是否属于给定的区间, 因为是顺序往下遍历, 只需要判断是否超出了 右边界 即可

 

这里是将 rec 转换为 mysql_rec 的地方

 

这里根据索引的区间判断是没有使用到 prebuilt->fetch_cache 的 

然后在迭代的过程中会依次比较 “field36”-> 36, “field37”->37 的记录信息, id 为 35 的记录 field1 为 “field33”, 索引是按照顺序排列的, 因此是不会遍历到索引 “field33” -> 35 -

迭代到 “field36” -> 36 的时候满足条件, 因此获取给定的记录返回回去

迭代到 “field37” -> 37 的时候, 一边是索引记录的值 “field37”, 另外一边是查询条件中的 “field37”

然后这里比较 两者相等, 外面根据查询条件是否包含 “等于”, 来更新这里的比较结果 

来符合我们的一个 “<”/”<=” 的一个计算需求 

 

我们这里查询条件为 “field1 < 'field37';”, 因此在 “field37” = “field37” 的场景下面是不满足需求的, 因此这里设置了一个 如果两者相等的时候的一个默认值, 这里为 1 表示 OUT_OF_RANGE

key_compare_result_on_equal 是在之前设置的, 根据查询条件动态调整 

 

然后外层 row_search_mvcc 控制着外层跳出循环 

 

然后外层 sub_select 跳出循环 

 

 

range 使用索引 or 不使用索引 ?

假设执行查询如下 “select * from tz_test where field1 > 'field33';”

这里比较的两个 estimate, 一个应该是 全表扫描 的开销, 另外一个是使用 field1 索引的开销 

cost 的 io_cost 为扫描的记录数量, cpu_cost 为计算的 cpu 开销 

allTableEstimate 的计算方式不太清楚, 这里合计为 23[每次计算可能有所差异, 我们这里仅仅以这次调试为例], 所以 可以推导出的是如果 range 查询记录数量超过了 23 是肯定使用 全表扫描 

 

假设执行查询如下 “select * from tz_test where field1 > 'field97';”

这里很显然就会使用 field1 字段的 range 查询 

 

假设执行查询如下 “select * from tz_test where field1 > 'field81';”

选择全表扫描 

 

假设执行查询如下 “select * from tz_test where field1 > 'field82';”

选择索引查询 

 

 

完