问一个 mysql 索引的问题:
背景信息:test 表上 a 字段有 btree 索引
有这样一个查询语句:
select * from test where a = 1 order by b desc
有以下两种场景:
场景一:当 b 是普通索引的时候,explain 结果会使用到 using filesort 这样的关键字(为了不进行 filesort ,需要对 a 和 b 两个字段建立联合索引);
场景二:b 是主键索引的时候 explain 的结果确是 using where ;
我的理解:
场景一是符合预期的,因为在 a 的 btree 索引上并不能保证 b 字段的有序性,所以会使用到 filesort ;
场景二我理解是因为 a 字段的 btree 索引本身就是带有主键 id 这个信息的(理解是为了回表用的)
但是我不太理解的是,为什么这里的主键 id 排序不需要走 filesort ,是否可以理解为表中任意字段的 btree 索引其实等价于字段索引+主键索引的组合索引,如果这么理解的话是可以解释的通的,我不太确定的是内部机制是否真的是这样实现的?还是说依赖了主键索引其他方面的能力才导致不需要走 filesort ?
背景信息:test 表上 a 字段有 btree 索引
有这样一个查询语句:
select * from test where a = 1 order by b desc
有以下两种场景:
场景一:当 b 是普通索引的时候,explain 结果会使用到 using filesort 这样的关键字(为了不进行 filesort ,需要对 a 和 b 两个字段建立联合索引);
场景二:b 是主键索引的时候 explain 的结果确是 using where ;
我的理解:
场景一是符合预期的,因为在 a 的 btree 索引上并不能保证 b 字段的有序性,所以会使用到 filesort ;
场景二我理解是因为 a 字段的 btree 索引本身就是带有主键 id 这个信息的(理解是为了回表用的)
但是我不太理解的是,为什么这里的主键 id 排序不需要走 filesort ,是否可以理解为表中任意字段的 btree 索引其实等价于字段索引+主键索引的组合索引,如果这么理解的话是可以解释的通的,我不太确定的是内部机制是否真的是这样实现的?还是说依赖了主键索引其他方面的能力才导致不需要走 filesort ?
