数据结构
什么样的数据结构作索引更好？
- 能在尽可能少的磁盘的 I/O 操作中完成查询工作，因为磁盘 I/O 操作越少，所消耗的时间也就越小。
- MySQL 是支持范围查找的，所以索引的数据结构不仅要能高效地查询某一个记录，而且也要能高效地执行范围查找。
B+ Tree VS B Tree
- 存储相同数量级别的情况下，B+Tree树比B Tree树的高度低，磁盘I/O次数更少。
- B+ Tree叶子节点用双向链表串起来，适合范围查询，B Tree无法做到这点。
B+ Tree VS 二叉树
- 随着数据量的增加，二叉树的树高会越来越高，磁盘I/O次数也会更多，B+Tree 在千万级别的数据量下，高度依然维持在3
4 层左右，也就是说一次数据查询操作只需要做 34次的磁盘I/O操作就能查询到目标数据。
B+ Tree VS Hash
- 虽然 Hash 的等值查询效率很高，但是无法做范围查询。
什么时候适合需要索引
- 字段有唯一性限制的，比如学生学号
- 经常用于WHERE查询条件的字段
- 经常用于 GROUP BY 和ORDER BY 的字段
什么时候不需要索引
- WHERE 条件，GROUP BY，ORDER BY 里用不到的字段
- 字段中存在大量重复数据，不需要创建索引;表数据太少的时候，不需要创建索引
- 经常更新的字段不用创建索引
什么时候索引失效
- 当我们使用左或者左右模糊匹配的时候，也就是like%xx或者like %xx%这两种方式都会造成索引失效
- 当我们在查询条件中对索引列做了计算、函数、类型转换操作，会导致索引失效
- 联合索引要能正确使用需要遵循最左匹配原则，也就是按照最左优先的方式进行索引的匹配，否则就会导致索引失效。
- 在WHERE 子句中，如果在 OR 前的条件列是索引列而在 OR 后的条件列不是索引列，那么索引会失效。为了更好的利用索引，索引列要设置为 NOT NULL约束。
索引优化
- 前缀索引优化
- 覆盖索引优化
- 主键索引最好是自增的
- 防止索引失效
