什么时候添加B+树索引呢？
在访问表中很少一部分时使用B+树索引才有意义。
Q: 怎么查看索引是否是高选择性的呢？
A：可以通过SHOW INDEX 结果中的列 Cardinality 来观察。Cardinality 表示索引中不重复记录数量的预估值。
Q: 为什么Cardinality 是预估值呢？
A : 因为Cardinality 是通过采样(Sample)的方法来完成的。默认InnoDB存储引擎会对8个叶子节点（Leaf Page)进行采用。
取得B+树索引中叶子节点的数量，记为A。随机取得B+树索引中的8个叶子节点。统计每个页不同记录的个数，即为P1,P2,...,P8.
根据采样信息给出Cardinality 的预估值：Cardinality = (P1+P2+....+P8) * A/8
Q: 更新Cardinality 的策略是什么呢？
A: 表中 1/16的数据已发生过变化。
stat_modified_counter>2 000 000 000. 变化次数
不同应用中B+树索引的使用
- 在具体的生产环境中使用索引，并观察索引使用的情况
- 判断是否真的需要使用索引，不要盲从任何人给你的经验意见，Think Different. => 独立思考，养成独立思考的习惯，关注实际问题。
联合索引
可以使用联合索引在一些 order by 的场景下去优化我们的Sql,减少查询的时间
覆盖索引
从辅助索引中就可以得到查询记录，而不需要查询聚集索引中的记录。使用覆盖索引的好处是辅助索引不包含整行记录的所有信息，故其大小要远小于聚集索引，因此可以减少大量的IO操作。也就是不回表。
某些统计问题可以走辅助索引，辅助索引小于聚集索引，可以减少IO操作。
优化器不走索引的情况
用户要选取的数据是整行数据信息，而辅助索引不能覆盖我们要查询的信息。因为走了辅助索引以后，我们还要进行一次书签访问来查找整行的数据细腻下。虽然辅助索引是顺序存放的，但是再一次进行书签查找的数据则是无序的，因为变为了磁盘上的离散读操作。 顺序读 > 离散读。
Multi-Range Read 优化
Multi-Range Read 优化的目的就是为了减少磁盘的随机访问，并且将随机访问转化为较为顺序的数据访问。
MRR 优化的好处：
- MRR 使数据访问变得较为顺序。在查询辅助索引时，首先根据得到的查询结果，按照主键进行排序，并按照主键排序的顺序进行书签查找。
- 减少缓冲池中页被替换的次数
- 批量处理对键值的查询操作
核心思路： 随机访问 =》较为顺序的数据访问。
Index Condition Pushdown(ICP) 优化
不使用索引下推：根据索引查找记录，然后再根据 WHERE 条件来过滤记录
支持索引下推： MySQL 数据库会在取出索引的同时，判断是否可以进行WHERE 条件的过滤
个人的一些思考：
-
建议还是直接写SQL, 不使用orm框架，因为直接写sql 你会很明确你要获取什么样的数据，怎么获取，也会去思考它的索引
-
如果不用全部字段拿出来，最好不要 select *