返回信息流想不通，索引是B+树结构，那"select id from table limit m,n"在m=几十上百万的时候，怎么能在树上快速定位其序号呢？
这是一条镜像帖。来源：北邮人论坛 / database / #11253同步于 2019/6/19
该镜像源已超过 30 天没有更新，可能在源站已被删除。
Database机器人发帖
为啥在mysql的覆盖索引上做limit操作非常快呢
yola
2019/6/19镜像同步6 回复
订阅后，新回复会通过你的通知中心匿名送达。
6 条回复
其实mysql表格主键也是一个索引，而普通的二级索引就是某个列值和主键的映射关系，如果是单纯地查找主键的值，那么执行引擎在索引上找到以后就不需要再回表查找了。
数据结构怎么学的，id是主键，按照id查找得话是随机查找，按MySQL的执行计划属于const类型，在mysql执行计划中其次快的是re_conf,ref,range,index,all
使用索引的时候，索引是单独的一个文件，里面包含这个索引列的所有值，而不使用索引的话是返回整行整行的数据。而且索引这个文件是存在内存上的，没有和磁盘的io
楼上们讲的都很对，但不是我提的问题呀~
我问的不是“为啥在覆盖索引搜索到结果会比在全表的实际存储位置搜索快”
而是问的“为啥在覆盖索引能迅速的找到排序第500万的那个位置的那条数据”，也就是limit 5000000,10为啥在覆盖索引上定位快
因为在B+tree上，节点们没有自己排在第几个位置信息吧？
b+tree都得在叶子节点挨个遍历500w次，才能找到那个节点，为啥覆盖索引不用呢？
【 在 yola 的大作中提到: 】
: 楼上们讲的都很对，但不是我提的问题呀~
: 我问的不是“为啥在覆盖索引搜索到结果会比在全表的实际存储位置搜索快”
: 而是问的“为啥在覆盖索引能迅速的找到排序第500万的那个位置的那条数据”，也就是limit 5000000,10为啥在覆盖索引上定位快
: ...................