聚集索引辅助索引覆盖索引联合索引filesort过程

Posted 2022-06-04 java_wxid

文章目录

• • 什么是聚集索引
  • 什么是辅助索引
  • 什么是覆盖索引，什么情况下优化器会选择使用覆盖索引
  • 什么是联合索引，联合索引的使用经验有吗？
  • 索引总结
  • filesort的过程

什么是聚集索引

InnoDB存储引擎表是索引组织表，即表中数据按照主键顺序存放。而聚集索引（clusteredindex）就是按照每张表的主键构造一棵B+树，同时叶子节点中存放的即为整张表的行记录数据，也将聚集索引的叶子节点称为数据页。每个数据页都通过一个双向链表来进行链接由于实际的数据页只能按照一棵B+树进行排序，因此每张表只能拥有一个聚集索引。在多数情况下，查询优化器倾向于采用聚集索引。因为聚集索引能够在B+树索引的叶子节点上直接找到数据。此外，由于定义了数据的逻辑顺序，它对于主键的排序查找和范围查找速度非常快。叶子节点的数据就是用户所要查询的数据如：用户需要查询一张注册用户的表，查询最后注册的10位用户，由于B+树索引是双向链表的，用户可以快速找到最后一个数据页，并取出10条记录SELECT * FROM Profile ORDER BY id LIMIT 10;虽然使用ORDER BY对主键id记录进行排序，但是在实际过程中并没有进行所谓的filesort操作，而这就是因为聚集索引的特点。另一个是范围查询（range query），即如果要查找主键某一范围内的数据，通过叶子节点的上层中间节点就可以得到页的范围，之后直接读取数据页即可。如：SELECT * FROM Profile where id>1 and id < 100;

什么是辅助索引

对于辅助索引（Secondary Index，也称非聚集索引），叶子节点并不包含行记录的全部数据。叶子节点除了包含键值以外，每个叶子节点中的索引行中还包含了一个书签（bookmark）。该书签用来告诉InnoDB存储引擎哪里可以找到与索引相对应的行数据。由于InnoDB存储引擎表是索引组织表，因此InnoDB存储引擎的辅助索引的书签就是相应行数据的聚集索引键。辅助索引的存在并不影响数据在聚集索引中的组织，因此每张表上可以有多个辅助索引。当通过辅助索引来寻找数据时，InnoDB存储引擎会遍历辅助索引并通过叶级别的指针获得指向主键索引的主键，然后再通过主键索引来找到一个完整的行记录。举例来说，如果在一棵高度为3的辅助索引树中查找数据，那需要对这棵辅助索引树遍历3次找到指定主键，如果聚集索引树的高度同样为3，那么还需要对聚集索引树进行3次查找，最终找到一个完整的行数据所在的页，因此一共需要6次逻辑IO访问以得到最终的一个数据页。

什么是覆盖索引，什么情况下优化器会选择使用覆盖索引

InnoDB存储引擎支持覆盖索引（covering index，或称索引覆盖），即从辅助索引中就可以得到查询的记录（此时不能够使用select * 操作，只能对特定的索引字段进行select），而不需要查询聚集索引中的记录。使用覆盖
索引的一个好处是辅助索引不包含整行记录的所有信息，故其大小要远小于聚集索引，因此可以减少大量的IO操作。对于InnoDB存储引擎的辅助索引而言，由于其包含了主键信息，因此其叶子节点存放的数据为（primarykey1，primary key2，…，key1，key2，…）。例如，下列语句都可仅使用一次辅助联合索引来完成查询：

SELECT key2 FROM table WHERE key1=xxx；
SELECT primary key2,key2 FROM table WHERE key1=xxx；
SELECT primary key1,key2 FROM table WHERE key1=xxx；
SELECT primary key1,primary key2,key2 FROM table WHERE key1=xxx；

CREATETABLEbuy_log( 
userid INT UNSIGNED NOT NULL,
buy_date DATE 
)ENGINE=InnoDB; 
ALTER TABLE buy_log ADD KEY (userid);
ALTER TABLE buy_log ADD KEY (userid,buy_date);

覆盖索引的另一个好处是对某些统计问题而言的。还是对于上题创建的表buy_log，要进行举例说明。
SELECT COUNT(*) FROM buy_log;InnoDB存储引擎并不会选择通过查询聚集索引来进行统计。由于buy_log表上还有辅助索引，而辅助索引远小于聚集索引，选择辅助索引可以减少IO操作。

在通常情况下，诸如（a，b）的联合索引，一般是不可以选择列b中所谓的查询条件。但是如果是统计操作，并且是覆盖索引的，则优化器会进行选择，如下述语句：SELECT COUNT(*)FROM buy_log WHERE buy_date＞=‘2011-01-01’ANDbuy_date＜’2011-02-01’
表buy_log有（userid，buy_date）的联合索引，这里只根据列b进行条件查询，一般情况下是不能进行该联合索引的，但是这句SQL查询是统计操作，并且可以利用到覆盖索引的信息，因此优化器会选择该联合索引.

什么是联合索引，联合索引的使用经验有吗？

联合索引是指对表上的多个列进行索引。

CREATE TABLE buy_log(
userid INT UNSIGNED NOT NULL,
buy_date DATE
)ENGINE=InnoDB;
ALTER TABLE buy_log ADD KEY (userid);
ALTER TABLE buy_log ADD KEY (userid,buy_date);

以上代码建立了两个索引来进行比较。两个索引都包含了userid字段。

情况1： 如果只对于userid进行查询，如：SELECT * FROM buy_log WHERE userid=2;索引选择：优化器最终的选择是索引userid，因为该索引的叶子节点包含单个键值，所以理论上一个页能存放的记录应该更多。

情况2：SELECT * FROM buy_log WHERE userid=1 ORDER BY buy_date DESC LIMIT 3；索引选择：优化器使用了（userid，buy_date）的联合索引userid_2，因为在这个联合索引中buy_date已经排序好了。根据该联合索引取出数据，无须再对buy_date做一次额外的排序操作。

情况 3：假如三个字段的联合索引。如：对于联合索引（a，b，c）来说，下列语句同样可以直接通过联合索引得到结果，不需要filesort的排序操作：

SELECT...FROM TABLE WHERE a=xxx ORDER BY b 
SELECT...FROM TABLE WHERE a=xxx AND b=xxx ORDER BY c

但是对于下面的语句，联合索引不能直接得到结果，其还需要执行一次filesort排序操作，因为索引（a，c）并未排序：

SELECT...FROM TABLE WHERE a=xxx ORDER BY c

索引总结

聚集索引的叶子节点称为数据页，每个数据页通过一个双向链表来进行链接，而且数据页按照主键的顺序进行排列。每个数据页上存放的是完整的行记录，而在非数据页的索引页中，存放的仅仅是键值及指向数据页的偏移量，而不是一个完整的行记录。如果定义了主键，InnoDB会自动使用主键来创建聚集索引。如果没有定义主键，InnoDB会选择一个唯一的非空索引代替主键。如果没有唯一的非空索引，InnoDB会隐式定义一个主键来作为聚集索引。辅助索引它叶子节点中没有行记录的全部数据，叶子节点除了包含键值以外，每个叶子节点的索引行还包含了一个书签，该书签用来告诉InnoDB哪里可以找到与索引相对应的行数据。覆盖索引先遍历辅助索引，再遍历聚集索引，而如果要查询的字段值在辅助索引上就有，就不用再查聚集索引了，这显然会减少IO操作。除了这三种索引，还有一种联合索引，它是对表上的多个列进行索引，键值都是排序的，通过叶子节点可以顺序的读出所有数据，联合索引的好处在于能起到"一个顶三个"的作用。比如建了一个(a,b,c)的复合索引，那么实际等于建了(a),(a,b),(a,b,c)三个索引，每多一个索引，都会增加写操作的开销和磁盘空间的开销，对于大数据的表，这是不小的开销。另外它还可以避免filesort排序，因为filesort的过程，一行数据会被读两次，第一次是where条件过滤时，第二个是排完序后还得用行指针去读一次。

filesort的过程

filesort的过程是这样的：第一步先根据表的索引或者全表扫描，读取所有满足条件的记录。第二步，存储每一行排序列，就是order by用到的列值，还有行记录指针，就是指向该行数据的行指针，把这二个存储到缓冲区。第三步，当缓冲区满后，运行一个快速排序来将缓冲区中数据排序，将排序完的数据存储到一个临时文件，保存一个存储块的指针，当然如果缓冲区不满，则不会重建临时文件了。直到将所有行读完，建立相应有序的临时文件。第四步，对块级进行排序，这个类似归并排序算法，只通过两个临时文件的指针来不断交换数据，最终达到两个文件，都是有序的，直到所有的数据都排序完毕。第五步，采取顺序读的方式，将每行数据读入内存，取出数据传到客户端。

为什么要说这个filesort呢？举二个场景，第一个，如果order by的条件不在索引列上会产生filesort，第二个，排序的字段不在where的条件中，没有办法走索引排序Index，而是走的文件排序filesort 。这种概率其实还是挺高的。这个时候就需要看文件排序用的是单路排序还是双路排序，单路排序会把所有需要查询的字段都放到 sort buffer 中，而双路排序只会把主键 和需要排序的字段放到 sort buffer 中进行排序，然后再通过主键回到原表查询需要的字段。mysql优化器使用双路排序还是单路排序是有自己的算法判断的，如果查询的列字段大于max_length_for_sort_data变量，则会使用双路排序，反之则会使用单路排序，单路排序速度是更快的，不过比较占据内存，如果在内存空间允许的情况下想要使用单路排序的话，可以增加max_length_for_sort_data变量的大小，max_length_for_sort_data变量默认为1024字节。