共计 2531 个字符，预计需要花费 7 分钟才能阅读完成。
聚集索引（clustered index）
innodb 存储引擎表是索引组织表，表中数据按照主键顺序存放。其聚集索引就是按照每张表的主键顺序构造一颗 B + 树，其叶子结点中存放的就是整张表的行记录数据，这些叶子节点成为数据页。
聚集索引的存储并不是物理上连续的，而是逻辑上连续的，叶子结点间按照主键顺序排序，通过双向链表连接。多数情况下，查询优化器倾向于采用聚集索引，因为聚集索引能在叶子结点直接找到数据，并且因为定义了数据的逻辑顺序，能特别快的访问针对范围值的查询。
聚集索引的这个特性决定了索引组织表中的数据也是索引的一部分。由于表里的数据只能按照一颗 B + 树排序，因此一张表只能有一个聚簇索引。
在 Innodb 中，聚簇索引默认就是主键索引。如果没有主键，则按照下列规则来建聚簇索引:
没有主键时，会用一个非空并且唯一的索引列做为主键，成为此表的聚簇索引;
如果没有这样的索引，InnoDB 会隐式定义一个主键来作为聚簇索引。
由于主键使用了聚簇索引，如果主键是自增 id，那么对应的数据也会相邻地存放在磁盘上，写入性能较高。如果是 uuid 等字符串形式，频繁的插入会使 innodb 频繁地移动磁盘块，写入性能就比较低了。
B+ 树（多路平衡查找树）
我们知道了 innodb 引擎索引使用了 B + 树结构，那么为什么不是其他类型树结构，例如二叉树呢？
计算机在存储数据的时候，有最小存储单元，这就好比人民币流通最小单位是分一样。文件系统的最小单元是块，一个块的大小是 4k（这个值根据系统不同并且可设置），InnoDB 存储引擎也有自己的最小储存单元—页（Page），一个页的大小是 16K（这个值也是可设置的）。
文件系统中一个文件大小只有 1 个字节，但不得不占磁盘上 4KB 的空间。同理，innodb 的所有数据文件的大小始终都是 16384（16k）的整数倍。
所以在 MySQL 中，存放索引的一个块节点占 16k，mysql 每次 IO 操作会利用系统的预读能力一次加载 16K。这样，如果这一个节点只放 1 个索引值是非常浪费的，因为一次 IO 只能获取一个索引值，所以不能使用二叉树。
B+ 树是多路查找树，一个节点能放 n 个值，n = 16K / 每个索引值的大小。例如索引字段大小 1Kb，这时候每个节点能放的索引值理论上是 16 个，这种情况下，二叉树一次 IO 只能加载一个索引值，而 B + 树则能加载 16 个。
B+ 树的路数为 n +1，n 是每个节点存在的值数量，例如每个节点存放 16 个值，那么这棵树就是 17 路。
从这里也能看出，B+ 树节点可存储多个值，所以 B + 树索引并不能找到一个给定键值的具体行。B+ 树只能找到存放数据行的具体页，然后把页读入到内存中，再在内存中查找指定的数据。
附：B 树和 B + 树的区别在于，B+ 树的非叶子结点只包含导航信息，不包含实际的值，所有的叶子结点和相连的节点使用链表相连，便于区间查找和遍历。
辅助索引
也称为非聚集索引，其叶子节点不包含行记录的全部数据，叶子结点除了包含键值以外，每个叶子结点中的索引行还包含一个书签，该书签就是相应行的聚集索引键。
如下图可以表示辅助索引和聚集索引的关系（图片源自网络，看大概意思即可）：
当通过辅助索引来寻找数据时，innodb 存储引擎会通过辅助索引叶子节点获得只想主键索引的主键，既然后再通过主键索引找到完整的行记录。
例如在一棵高度为 3 的辅助索引树中查找数据，那需要对这颗辅助索引树进行 3 次 IO 找到指定主键，如果聚集索引树的高度同样为 3，那么还需要对聚集索引树进行 3 次查找，最终找到一个完整的行数据所在的页，因此一共需要 6 次 IO 访问来得到最终的数据页。
创建的索引，如联合索引、唯一索引等，都属于非聚簇索引。
联合索引
联合索引是指对表上的多个列进行索引。联合索引也是一颗 B + 树，不同的是联合索引的键值数量不是 1，而是大于等于 2。
例如有 user 表，字段为 id，age，name，现发现如下两条 sql 使用频率最多：
Select * from user where age =？;
Select * from user where age = ? and name = ?;
这时候不需要为 age 和 name 单独建两个索引，只需要建如下一个联合索引即可：
create index idx_age_name on user(age, name)
联合索引的另一个好处已经对第二个键值进行了排序处理，有时候可以避免多一次的排序操作。
覆盖索引
覆盖索引，即从辅助索引中就可以得到查询所需要的所有字段值，而不需要查询聚集索引中的记录。覆盖索引的好处是辅助索引不包含整行记录的所有信息，故其大小要远小于聚集索引，因此可以减少大量的 IO 操作。
例如上面有联合索引（age，name），如果如下：
select age，name from user where age=？
就能使用覆盖索引了。
覆盖索引的另一个好处是对于统计问题，例如：
select count(*) from user
innodb 存储引擎并不会选择通过查询聚集索引来进行统计。由于 user 表上还有辅助索引，而辅助索引远小于聚集索引，选择辅助索引可以减少 IO 操作。
注意事项
索引只建合适的，不建多余的
因为每当增删数据时，B+ 树都要进行调整，如果建立多个索引，多个 B + 树都要进行调整，而树越多、结构越庞大，这个调整越是耗时耗资源。如果减少了这些不必要的索引，磁盘的使用率可能会大大降低。
索引列的数据长度能少则少。
索引数据长度越小，每个块中存储的索引数量越多，一次 IO 获取的值更多。
匹配列前缀可用到索引 like 9999%，like %9999%、like %9999 用不到索引；
Where 条件中 in 和 or 可以使用索引，not in 和 <> 操作无法使用索引；
如果是 not in 或 <>，面对 B + 树，引擎根本不知道应该从哪个节点入手。
匹配范围值，order by 也可用到索引；
多用指定列查询，只返回自己想到的数据列，少用 select *；
不需要查询无用字段，并且不使用 * 可能还会命中覆盖索引哦；
联合索引中如果不是按照索引最左列开始查找，无法使用索引；
最左匹配原则；
联合索引中精确匹配最左前列并范围匹配另外一列可以用到索引；
联合索引中如果查询中有某个列的范围查询，则其右边的所有列都无法使用索
本文作者：信~ 仰阅读原文
本文为云栖社区原创内容，未经允许不得转载。
