mysql查看sql代价_mysql 代价

mysql cbo cost base optimizer 基于代价，数据是一直变化的

mysql有表空间吗、oracle8 以前是rbo rule base optimizer 基于规则, 如果sql使用了索引，必须使用索引,尽管全表扫描比索引快

代价= cpu cost + io cost

MySQL 漏洞。1)计算全表扫描代价

a)cpu cost

MySQL limit？(double) records / TIME_FOR_COMPARE + 1

records为表会统计的所有记录个数

TIME_FOR_COMPARE 为5，即CPU每比较5条记录，计1个cost, 是mysql层统计

b)io cost

(double) (prebuilt->table->stat_clustered_index_size

聚簇索引叶页面数

2)索引范围扫描代价

a)主键，唯一索引 io cost

a1)cpu cost

范围查找估算的记录/TIME_FOR_COMPARE+1

a2)io cost

(range+row)/(总记录/聚焦索引的页面数)

通过范围查找，估算出有100条记录，总记录500条，共有20个page

那么一个page能装载500/20=25条记录，那100条记录 需要 100/25=4条记录来装载

b)二级索引覆盖索引

b1)cpu cost

范围查找估算的记录数/TIME_FOR_COMPARE+1

b2)io cost

范围查找估算的记录数/keys_per_page

c)二级索引 非覆盖索引

c1)cpu cost

范围查找估算的记录数/TIME_FOR_COMPARE+1

c2)io cost

范围查找估算的记录数, 需要回表，但可能对应的主键有若干个在同一个page

关于mysql cost 成本的计算方式，感觉计算过程是不太合理的，也常常是不精确的，计算结果倾向于进

行全表扫描，在mysql 中，cost 成本模型是分别计算cpu cost 和io cost,然后把两者相加而得到最终的

总成本， 并没有考虑到CPU&IO 的权重因素、机器CPU 实际处理速度、 IO 的实际能力和当前的负载等因素，

对这块的统计数据也没有收集操作。

公式简要说明如下：

单表时：

COST = io_cost + cpu_cost;

| |

| |

V V

read_time + found_records / (double) TIME_FOR_COMPARE==5

其中的read_time 和found_records 计算过程按不同的type 如下：

当type 为:

system & const: //const_tab

{

found_records=read_time=1;

}

当type 为:

Index : //covering index

{

uint keys_per_block= (index_block_size/2/key_len) + 1); //块一半满，除以键长度

read_time=((double) (records+keys_per_block-1)/(double) keys_per_block);

found_records = ranges 区间扫描得到的总行数;(当存储引擎不支持index filter 时，

为下行扇出的记录条数和)

}

当type 为:

Ref_[OR_null]: //ref

{

read_time = found_records + ranges;

found_records = ranges 区间扫描得到的总行数; (当存储引擎不支持index filter 时，

为下行扇出的记录条数和)

}

DEFAULT:(type 其实为all)

found_records=全表记录;

read_time= 全索引pages 数目;

join时为:

总cost= 前表cost + 后表cost * 前表found_records

(采用贪婪算法，找出谁先谁后顺序进行join.)

估算card 时，部分动作可以触发统计信息的收集，包括analyze、show table status 等，在innodb

中为8 个分散索引块扫描后计算得到的，也看到有人改为用64 块进行统计信息的收集，同时关闭参数

innodb_stats_method，以保证执行计划的稳定性。