第12章 谁最便宜就选谁-MySQL基于成本的优化
什么是成本
查询的时候MySQL总是根据最低成本选择查询方法，但是这个成本具体是什么呢？
（1）I/O成本
查询记录都是将数据或者索引加载到内存中进行的操作，这个加载的时间损耗称之为I/O成本，也就是时间成本
（2）CPU成本
读取和筛选都需要时间，损耗的时间称之为CPU成本。其实也很好理解，因为这些工作都是交给CPU来处理的，CPU花时间才能得到结果
对于InnoDB存储引擎来说，页是磁盘和内存的交互的基本单位，固定一个页面花费的成本是1，查询一条符合要求的记录是0.2。这些数字称之为成本常数
单表查询成本
执行查询之前优化器会找到所有可能实现的方案，然后选择一个最优的方案------成本最低的选择
这个最终准备执行的方案就是执行计划。然后通过它调用存储引擎的结果执行查询
总结一下过程：
（1）根据条件找出所有可用的索引
（2）预估全盘扫描的代价
（3）计算使用索引的代价
（4）对比各种方案的成本，选择成本最低的
（1）查找所有可用的索引
只要搜索条件可能使用到索引（比如=、 IS NOT这些），那么就根据条件查找即可
可能使用到的索引称之为possible keys
（2）全盘扫描的代价
对于InnoDB来说就是将主键值B+树（聚簇索引）中的记录和筛选条件进行筛选。得到符合要求的结果集
因此需要将语句索引加载到内存中，然后检测记录是否符合要求，再根据两个常数计算查询成本：
页面数 + 记录数
这些信息是自动统计的。
然后通过这些信息计算：
I/O成本 + CPU成本
（3）计算使用不同索引执行查询的代价
优化器先分析唯一的二级索引（如果有的话），然后再分析普通索引的查询成本。总之就是分别单独分析不同的索引的查询成本。
期间可能还可以使用索引合并
同样的，还是使用成本常数进行两个成本的计算
默认读取一个索引区间范围内的I/O成本和读取一个页是一样的：通过一个范围得到一个索引I/O成本
然后使用算法求出范围内的记录数，计算得到CPU成本
回表还会带来I/O成本
回表得到记录以后还需要满足其他的搜索条件，这也需要CPU成本
将上述的所有成本加起来就是最终的成本了
（4）对比各种方案，选择最合适的
这里就比较简单了，直接就是比较各个方案的成本数值，选出最低的成本方案即可
基于索引统计数据的成本计算
有时候使用索引执行查询的时候会有许多的单点区间，比如使用IN语句就会产生很多的单点区间：
SELECT * FROM single_table WHERE key1 IN ('aaa',`````);
MySQL使用index dive的方式来计算记录数：通过访问索引对应的B+树来计算记录的条数：获取最左边和最右边的记录，然后数个数即可
但是如果IN语句里面丢了很多的参数，那么这样的方法可就应付不过来了
于是MySQL的设计师设计了一个门限系统变量：range-index-dive-limit
一般超过200个就不使用index dive方法了，而是使用索引统计数据：
该表中的记录数和索引列中不重复值的个数（Cardinality属性）
有这两个参数就可以计算索引列中单个值重复出现的次数：
应用：
假如IN后面跟了300个参数，一个参数大约对应10条记录
那么估算出需要回表的记录数是： 300 * 10 = 3000
总之这是一个粗略的算法，具体来说的细节其实我并不关心哈哈哈哈💦
知道这个方法就是一个估算回表数的一个算法即可
连接查询的成本
MySQL的连接本质上是全套循环的连接算法，所以对于两表连接查询的来说，成本由两部分组成：
单次查询驱动表的成本，多次查询被驱动表的成本
具体成本的计算MySQL是设计了一个猜的方案，具体怎么才到过程是condition filtering
到底怎么实现的就不用关心了，可能非常复杂，只用知道这个过程是靠猜测实现的
两表连接的成本分析
多表连接的成本分析
调节成本常数
总结：
我个人认为这一章主要是介绍优化器选择方案的方式------成本选择
我感觉具体的原理不用很深入的学习，了解一下作用机制即可，全部掌握细节未免太过于枯燥了害害害💦