1
JKeita 2023-06-07 09:14:37 +08:00
id 索引本来就有序啊
|
2
doraf 2023-06-07 09:27:29 +08:00
我认为你的理解是对的。
这个页面 https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.html 上说, Indexes other than the clustered index are known as secondary indexes. In InnoDB, each record in a secondary index contains the primary key columns for the row, as well as the columns specified for the secondary index. InnoDB uses this primary key value to search for the row in the clustered index. |
3
realpg 2023-06-07 09:35:44 +08:00
我记得 innodb 的普通索引机制是利用了主键的
|
4
awalkingman 2023-06-07 09:38:40 +08:00
“是否可以理解为表中任意字段的 btree 索引其实等价于字段索引+主键索引的组合索引” ==> 是的,所有 btree 索引都可以认为是 目标索引后面加个 id (主键)的 联合索引。
|
5
zjq07 2023-06-07 09:49:14 +08:00 1
所有的非聚簇索引,都可以认为是(索引列+主键 id )的联合索引
|
6
awalkingman 2023-06-07 09:51:05 +08:00
@zjq07 正解,我的表述不准确
|
10
nothingistrue 2023-06-07 15:34:07 +08:00 1
Mysql InnoDB 引擎下,有两个特殊性:一,主键索引是聚集索引,主键索引就是最终数据存储;二,基于一,其他索引指向的目的地是主键,而非通常的隐藏 rownum 。
对于特殊性一,因为主键索引就是全部数据,而你只用主键做排序条件,主键索引又是 btree 的天然具有顺序性,所以就无需做排序了,直接在主键索引上筛选数据就够了。这就是你 explain 只看到 using where 的原因。 对于特殊性二,a 字段的 btree 索引上,索引值就是 b 字段的值,故全部查询内容都在这个索引上,可以直接在这个索引上做查询和排序,也不用回落数据文件。当然这个并没有被采用,因为用特殊性一的处理会更快。 |
11
iosyyy 2023-06-07 20:09:36 +08:00
对于 innodb 来说他的数据和 id 是存在一起的 btree 底层具有排序信息所以不需要额外对 id 排序 也就是不需要走 filesort
|