mysql优化级别range和ref_MySQL源码:Range和Ref优化的成本评估

在开始介绍index merge/ROR优化之前，打算先介绍MySQL是如何对range/ref做成本评估的。MySQL是基于成本(cost)模型选择执行计划，在多个range，全表扫描，ref之间会选择成本最小的作为最终的执行计划。仍然强烈建议先阅读登博的slide：《查询优化浅析》，文中

在开始介绍index merge/ROR优化之前，打算先介绍MySQL是如何对range/ref做成本评估的。MySQL是基于成本(cost)模型选择执行计划，在多个range，全表扫描，ref之间会选择成本最小的作为最终的执行计划。仍然强烈建议先阅读登博的slide：《查询优化浅析》，文中较为详细的介绍MySQL在range优化时成本的计算。

本文将继续介绍range/ref执行计划选择的一些不容忽略的细节。希望看客能够通过此文能够了解更多细节。

目录0. 成本计算的总原则

1. range成本的计算与分析1.1 range返回的记录数

1.2 CPU COST

1.3 IO COST

1.4 全表扫描的成本

1.5 关于range执行计划的分析

1.6 验证

1.7 一些限制

2. ref成本的计算与分析2.1 ref返回的记录数

2.2 CPU COST

2.3 IO COST

2.4 全表扫描的成本

2.5 关于ref执行计划的分析

2.6 验证

3. 上面计算的局限性

4. 案例中使用的数据和表

0. 成本计算的总原则

MySQL的一个执行计划，有两部分成本，CPU成本(CPU COST)和IO成本(IO COST)。CPU COST是指查询出纪录后，需要做过滤等处理的时候的CPU消耗，IO COST是指，从存储引擎读取数据时需要做的IO消耗。

总成本 ＝ CPU COST + IO COST

补充说明：(1) IO成本计算不考虑缓存的影响。因为在优化器本身是无法预知需要的数据到底在内存中还是磁盘上。

1. range成本的计算与分析

MySQL使用一颗SEL_ARG的树形结构描述了WHERE条件中的range，如果有多个range，则使用递归的方式遍历SEL_ARG结构，在前面详细的介绍range的红黑树结构，以及MySQL如何遍历之。

接上文，这里将看看，遍历到最后，MySQL如何计算一个简单range的成本。

1.1 range返回的记录数

MySQL首先计算range需要返回都少纪录，通过函数check_quick_select返回对某个索引做range查询大约命中多少条纪录。

found_records= check_quick_select(param, idx, *key, update_tbl_stats);

1.2 CPU COST

#define TIME_FOR_COMPARE 5 // 5 compares == one read

double cpu_cost= (double) found_records / TIME_FOR_COMPARE;

1.3 IO COST

对于InnoDB的二级索引，且不是覆盖扫描：

found_read_time := number of ranges + found_records

这里，found_records是主要部分，number of ranges表示一共有多少个range，这是一个修正值，表示IO COST不小于range的个数。

1.4 全表扫描的成本

具体的，对于InnoDB表，我们来看：

read_time= number of total page + (records / TIME_FOR_COMPARE + 1) + 1.1;

对于InnoDB取值为：主键索引(数据)所使用的page数量(stat_clustered_index_size)

对于MyISAM取值为：stats.data_file_length/IO_SIZE + file->tables

1.5 关于range执行计划的分析

这里来看看，range的选择度(selectivty)大概为多少的时候，会放弃range优化，而选