本文主要记录本人对innodb获取用于优化的统计信息代码的阅读与理解。
1. 背景信息
其中优化是mysql中最复杂的一块代码之一。 它主要的功能是生成高效的执行计划。 所谓的执行计划，就是对查询相关表的使用顺序，以及对每个表使用哪种方式进行数据操作。
其中t1中有主键c1, t2中有索引c2. 那么如下的这条查询语句
c1,c2 from t1,t2 where c1 between 0 and 10 and c2 = 8”;
可能的优化计划是首先打开t1表，使用c1的range索引进行数据读取，然后打开t2用c2的ref索引进行数据读取。
当然也有可能会先打开t2，然后再打开t1，并且读取数据的方式也有可能是别的。 而这些选择的依据就是这两个innodb表的统计信息。 这些统计信息中最最重要的就是用于描述数据分布情况的cardinality数据，这个值表示索引的唯一值有多少，该值可以通过show index来查看。
2. 概述
具体的我们可以看一段Planet MySQL上的解释：
虽然这段文字的功能是在介绍这种方式的弊端，但并不妨碍我们用来理解innodb的具体实现。 我们可以看出innodb的统计信息其实是一个不太准确的评估值，评估样本的数量默认上是8，即取8个页块的样本数据。这个数量可以通过选项innodb_stats_sample_pages来配置。
innodb中数据与索引一起存放在主键的b-tree中，该b-tree的叶子节点的构成为： 唯一的主键字段，然后用data域来保存这条主键对应的完整的数据记录。 而二级索引将会保存对应的主键字段，并以此来最终定位数据。
这个图大体描述了innodb数据存储的结构，这里需要记住的主要是行是隶属于页的，一个页中会包含多个的行，而磁盘I/O读取的最小单位是页。
3. 具体代码解析
make_join_statistics中，mysql遍历所有的查询相关表，为每个表调用
“table->file->info(HA_STATUS_VARIABLE | HA_STATUS_NO_LOCK);” （4644）。
table->file指的是该表的存储引擎。这里就是innodb引擎。
之后的调用路径大体上为：
info ----->
----------> dict_stats_update() --------> dict_stats_update_transient() ----------->btr_estimate_number_of_different_key_vals().
最终从磁盘上获取样本数据，计算cardinality的过程发生在 函数btr_estimate_number_of_different_key_vals中（btr0cur.c的3546行）。
以下是该函数的缩略代码：
从这里开始是获取样本数据信息，btr_cur_open_at_rnd_pos是随机的从b-tree的叶节点中选取一个读取位置。然后获取该位置所在的页，该页的第一行。
然后循环地取下一行，并且比较这行与上行记录的主键字段。因为mysql是支持自动的前缀索引，以及将模糊匹配的索引自动转成范围索引（例如 where key like 'abc%', 这个可以转成 where
key>= abc and key<=abd）,所以这里innodb会记录这两行主键字段的前缀匹配个数，即从前往后匹配主键字段，当碰到不一样的字段时停止匹配，并记录位置。
然后再根据n_diff中的值去估算主键中不同的前缀所能标识出的不同记录行数，行数越多，说明这个主键前缀越有效。（stat_n_diff_key_vals[ j ] 存的是前 j 个前缀字段所能标识出的不同记录行数），这个统计信息会被用于优化中，用于执行计划的生成。
4. 小结与后记
所以可以看出，mysql 默认情况下和5.6之前的统计信息是不精确的，是个基于随机样本的估计值。而情况在5.6之后有了改进，具体的我们可以看Planet MySQL下面这段叙述：