05 | 深入浅出索引（下）

[git-zjx]

回表

回到主键索引树搜索的过程，称为回表。主要出现原因为查找的数据只有主键索引树上存在。

覆盖索引

如果索引覆盖了查询的需求，就叫覆盖索引，减少了树的搜索次数，避免了回表，能显著提升性能

最左前缀原则

只要满足索引的最左前缀，就可以使用该索引，这个最左前缀可以是联合索引的前 N 个字段，也可以是字符串索引的前 N 个字符

在建立联合索引时，如何安排索引的顺序？

• 如果通过调整顺序可以减少索引的数量，优先考虑
• 如果不得不维护另一个索引，则需要考虑空间，选择空间小的单独维护

索引下推

MySQL 5.6 引入索引下推优化（index condition pushdown），可以在索引遍历过程中，对索引包含的字段先判断，直接过滤不满足条件的数据，减少回表次数

[git-zjx]

树高取决于数据页的大小么？

树高其实取决于叶子树（数据行数）和“N叉树”的N。 而N是由页大小和索引大小决定的

[git-zjx]

覆盖索引必须要覆盖所有的查询条件中的列吗？

因为覆盖索引的目的就是”不回表“，所以只有索引包含了 where 条件部分和 select 返回部分的所有字段，才能实现这个目的

[git-zjx]

关于用索引的问题

有些文章说模糊查询时以%开头不会用到索引，但和实际操作有些不符。这里主要是因为用索引有一种用法是 顺序遍历索引

[git-zjx]

如下的表结构和业务场景中，ca 和 cb 的索引是否有必要存在？

CREATE TABLE `geek` (
  `a` int(11) NOT NULL,
  `b` int(11) NOT NULL,
  `c` int(11) NOT NULL,
  `d` int(11) NOT NULL,
  PRIMARY KEY (`a`,`b`),
  KEY `c` (`c`),
  KEY `ca` (`c`,`a`),
  KEY `cb` (`c`,`b`)
) ENGINE=InnoDB;

# 业务场景
select * from geek where c=N order by a limit 1;
select * from geek where c=N order by b limit 1;

ca 索引是没有必要创建的

主键 a，b 的聚簇索引组织顺序相当于 order by a,b ，也就是先按 a 排序，再按 b 排序，c 无序 索引 ca 的组织是先按 c 排序，再按 a 排序，同时记录主键 索引 cb 的组织是先按 c 排序，在按 b 排序，同时记录主键 所以，ca 索引可以去掉