{{ it.name }}
{{ it.text }}
explain format=json 可以打印详细的执行计划成本,下面两个示例将告诉你如何查看成本输出,以及如何计算成本。
表结构如下:
实例1
eval_cost
这个很简单,就是计算扇出的 CPU 成本。应用条件 k<200 时,需要扫描索引 18行,这里 18 是精确值(index dive),然后优化器用了一种叫启发式规则(heuristic)的算法估算出其中满足条件 id<100 的比例为 33.33%,进行 18*33.33% 次计算的 CPU 成本等于 18*33.33%*0.2=1.2,这里 0.2 是成本常数(即 row_evaluate_cost )。
注意:rows_examined_per_scan*filtered 才是扇出数,不能简单的用 rows_produced_per_join 来表示。
read_cost
这里包含了所有的 IO 成本 +(CPU 成本 - eval_cost)。我们先看下这个SQL的总成本应该怎么算:
访问二级索引 k_3 的成本:
IO 成本 = 1*1.0
查询优化器粗暴的认为读取索引的一个范围区间的 I/O 成本和读取一个页面是相同的,这个 SQL 中 k 字段的筛选范围只有 1 个:k < 200,而读取一个页面的 IO 成本为 1.0(即 io_block_read_cost);
CPU 成本 = 18*0.2
从 k 索引中取出 18 行数据后,实际还要再计算一遍,每行计算的成本为 0.2。
然后因为 select * 以及 where id<100 需要的数据都不在索引 k_3 中,所以还需要回表,回表成本:
IO 成本 = 18*1.0
从索引中取出满足 k<200 的数据一共是 18 行,所以 = 18*1.0;
CPU 成本 = 18*0.2
从这 18 行完整的数据中计算满足 id<100 的数据,所以也需要计算 18 次。
总成本 = 1*1.0+18*0.2+18*1+18*02=26.2。因为 eval_cost 算的是扇出的 CPU 成本:18*33.33%*0.2,所以 read_cost = 回表的 CPU 成本 - eval_cost,也可以这么算 rows_examined_per_scan*(1-filtered)*0.2。
join 查询的总成本计算公式简化:连接查询总成本 = 访问驱动表的成本 + 驱动表扇出数 * 单次访问被驱动表的成本。explain 执行计划详解 1 中有解释 filtered 在关联查询中的重要性。
在上面示例中:访问驱动表的成本 = 26.21,驱动表扇出数 = 18*33.33% = 6,单次访问驱动表的成本 = 1.0+0.2 总成本=26.21+6(1.0+0.2)=33.41
注意:驱动表和被驱动表的 read_cost、eval_cost 代表不一样的成本。