1.老样子，建个表

还是这张表，表里我创建了近10W条数据

CREATE TABLE demo_info(id INT NOT NULL auto_increment,key1 VARCHAR(100),key2 INT,key3 VARCHAR(100),key_part1 VARCHAR(100),key_part2 VARCHAR(100),key_part3 VARCHAR(100),common_field VARCHAR(100),PRIMARY KEY (id),KEY idx_key1 (key1),UNIQUE KEY uk_key2 (key2),KEY  idx_key3 (key3),KEY idx_key_part(key_part1, key_part2, key_part3)
)ENGINE = INNODB CHARSET=utf8mb4;

id列是主键，key1列是二级索引列。

2.从sql执行计划看Limit的影响

分析一下sql执行计划

explain select * from demo_info order by key1 limit 1;

在二级索引idx_key1中，key1列是有序的，查找按key1列排序的第1条记录，MySQL只需要从idx_key1中获取到第一条二级索引记录，然后直接回表取得完整的记录即可，这个很容易理解。

如果我们把上边语句的limit 1换成limit 10000, 1，则却需要进行全表扫描，并进行filesort，执行计划如下：

explain select * from demo_info order by key1 limit 10000, 1;

有的同学就很不理解了：limit 10000, 1也可以使用二级索引idx_key1呀，我们可以先扫描到第10001条二级索引记录，对第10001条二级索引记录进行回表操作就好了啊。

由于MySQL实现缺陷，不会出现上述的理想情况，它只会全表扫描+filesort，下边我们分析一下。

3. 从server层和存储引擎层分析Limit执行过程

MySQL其实是分为server层和存储引擎层的：

server层负责处理一些通用的事情，诸如连接管理、SQL语法解析、分析执行计划之类的东西
存储引擎层负责具体的数据存储，诸如数据是存储到文件上还是内存里，具体的存储格式是什么样的之类的。我们现在基本都使用InnoDB存储引擎，其他存储引擎使用的非常少了，所以我们也就不讨论其他存储引擎了。

MySQL中一条SQL语句的执行是通过server层和存储引擎层的多次交互才能得到最终结果的。先不用Limit子句举一个简单例子分析：

SELECT * FROM demo_info WHERE key1 > 'a' AND key1 < 'b' AND common_field != 'a';

server层会分析到上述语句可以使用下边两种方案执行：

方案一：使用全表扫描
方案二：使用二级索引idx_key1，此时需要扫描key1列值在('a', 'b')之间的全部二级索引记录，并且每条二级索引记录都需要进行回表操作。

server层会分析上述两个方案哪个成本更低，然后选取成本更低的那个方案作为执行计划。然后就调用存储引擎提供的接口来真正的执行查询了。

这里假设采用方案二，也就是使用二级索引idx_key1执行上述查询。那么server层和存储引擎层的执行过程如下：

server层：“去查查idx_key1二级索引的('a', 'b')区间的第一条记录，然后把回表后把完整的记录返给我”

InnoDB层：InnoDB就通过idx_key1二级索引对应的B+树，快速定位到扫描区间('a','b')的第一条二级索引记录，然后进行回表，得到完整的聚集索引记录返回给server层。 server层收到完整的聚集索引记录后，继续判断common_field!='a'条件是否成立，如果不成立则舍弃该记录，否则将该记录发送到客户端。然后对存储引擎说：“请把下一条记录给我”

注意：

此处将记录发送给客户端其实是发送到本地的网络缓冲区，缓冲区大小由net_buffer_length控制，默认是16KB大小。等缓冲区满了才真正发送网络包到客户端。

InnoDB层：InnoDB找到idx_key1的('a', 'b')区间的下一条二级索引记录，然后进行回表操作，将得到的完整的聚集索引记录返回给server层。

注意：

不论是聚集索引记录还是二级索引记录，都包含一个称作next_record的属性，各个记录根据next_record连成了一个链表，并且链表中的记录是按照键值排序的（对于聚集索引来说，键值指的是主键的值，对于二级索引记录来说，键值指的是二级索引列的值）。

server层收到完整的聚集索引记录后，继续判断common_field!='a'条件是否成立，如果不成立则舍弃该记录，否则将该记录发送到客户端。然后对存储引擎说：“请把下一条记录给我哈”

… 然后就不停的重复上述过程。

直到InnoDB发现根据二级索引记录的next_record获取到的下一条二级索引记录不在('a', 'b')区间中，就跟server层说：“('a', 'b')区间没有下一条记录了”

server层收到InnoDB说的没有下一条记录的消息，就结束查询。

现在大家就知道了server层和存储引擎层的基本交互过程了。

那limit在哪里起作用呢？

MySQL是在server层准备向客户端发送记录的时候才会去处理limit子句中的内容。 举个例子：

select * from demo_info order by key1 limit 10000, 1;

如果使用idx_key1执行上述查询，那么MySQL会这样处理：

server层向InnoDB要第1条记录，InnoDB从idx_key1中获取到第一条二级索引记录，然后进行回表操作得到完整的聚集索引记录，然后返回给server层。server层准备将其发送给客户端，此时发现还有个limit 10000, 1的要求，意味着符合条件的记录中的第10001条才可以真正发送给客户端，所以在这里先做个统计，我们假设server层维护了一个称作limit_count的变量用于统计已经跳过了多少条记录，此时就应该将limit_count设置为1。
server层再向InnoDB要下一条记录，InnoDB再根据二级索引记录的next_record属性找到下一条二级索引记录，再次进行回表得到完整的聚集索引记录返回给server层。server层在将其发送给客户端的时候发现limit_count才是1，所以就放弃发送到客户端的操作，将limit_count加1，此时limit_count变为了2。
… 重复上述操作
直到limit_count等于10000的时候，server层才会真正的将InnoDB返回的完整聚集索引记录发送给客户端。

从上述过程中我们可以看到，MySQL中是在实际向客户端发送记录前才会去判断limit子句是否符合要求，所以如果使用二级索引执行上述查询的话，意味着要进行10001次回表操作。server层在进行执行计划分析的时候会觉得执行这么多次回表的成本太大了，还不如直接全表扫描+filesort快呢，全表扫描+filesort就是把聚集索引中的记录都依次与给定的搜索条件进行比较，把符合搜索条件的记录再进行排序，MySQL认为这样操作的成本比多次回表成本低，所以就选择了后者执行查询。

MySQL是根据成本来选择对应索引查询的，如果你不知道成本怎么计算，可以看我前一篇MySQL查询为什么选择使用这个索引？——基于MySQL8.0.22索引成本计算

注意：
有一个点很容易混淆，走PRIMARY索引和全表扫描有什么区别呢？他们其实都是在聚集索引上操作的（聚集索引B+树的叶子结点是根据主键排好序的完整的用户记录，包含表里的所有字段），区别就在于

全表扫描将聚集索引B+树的叶子结点依次顺序扫描并判断条件，在以下几种情况会走全表扫描：

select * from demo_info这种无条件的查询语句

select * from demo_info where common_field != 'a'这种条件字段common_field没有建索引的情况

select * from demo_info order by key1 limit 10000, 1条件字段key1建了索引但是MySQL认为走二级索引的成本比全表扫描成本高的情况。

PRIMARY索引是利用二分思想将聚集索引B+树到指定范围区间进行扫描，比如select * from demo_info where id in (1, 2)这种条件字段是主键id，可以很好的利用PRIMARY索引进行二分的快速查询。

怎么解决这个问题？

由于MySQL实现limit子句的局限性，在处理诸如limit 10000, 1这样的语句时就无法通过使用二级索引来加快查询速度了么？其实也不是，只要把上述语句改写成：

select * from demo_info d,
(select id from demo_info order by key1 limit 10000, 1) t
WHERE d.id = t.id;
-- 或者这么写
select * from demo_info d
join
(select id from demo_info order by key1 limit 10000, 1) t
on d.id = t.id

这样，select id from demo_info order by key1 limit 10000, 1作为一个子查询单独存在，由于该子查询的查询列表只有一个id列，MySQL可以通过仅扫描二级索引idx_key1的叶子结点不用回表，然后再根据子查询中获得到的主键值去表demo_info中进行查找。这样就省去了前10000条记录的回表操作，从而大大提升了查询效率！

欢迎一键三连~

有问题请留言，大家一起探讨学习

----------------------Talk is cheap, show me the code-----------------------

要想通过面试，MySQL的Limit子句底层原理你不可不知相关推荐

要想通过面试，MySQL的 Limit 子句底层原理你不可不知
点击关注公众号,实用技术文章及时了解来源:liuchenyang0515.blog.csdn.net/article/ details/120727513 文章目录老样子,建个表从sql执行计划 ...
MySQL的Limit子句
MySQL的Limit子句 Limit子句可以被用于强制 SELECT 语句返回指定的记录数,可以用来分页. 一.Limit子句参数用法 Limit接受一个或两个数字参数.参数必须是一个整数常量. 一 ...
腾讯一面：说一说 MySQL 中索引的底层原理
一.前言最近有很多读者要我出一些面试题的文章,一般我会给他一个老周整理的电子书,但有些读者反馈回来的面试题我觉得还是蛮经典的,而老周又在写系列的文章,本着对读者负责的态度,我会穿插写几篇我认为比较经 ...
MySQL 优化上来就分库分表？面试官：根本不懂底层原理！
孙玄,江湖人称"玄姐",前58集团技术委员会主席,前转转二手交易平台首席架构师.今天想跟你聊点儿企业里那些年薪百万的架构师,他们的架构设计思维是如何升级的,以及他们是如何玩转 My ...
面试必备：synchronized的底层原理？
最近更新的XX必备系列适合直接背答案,不深究,不喜勿喷. 你能说简单说一下synchronize吗? 可别真简单一句话就说完了呀~ 参考回答: synchronize是java中的关键字,可以用来修饰 ...
我向面试官讲解了hashmap底层原理，他对我竖起了大拇指
前言: 正值金九银十的黄金招聘期,大家都准备好了吗?HashMap是程序员面试必问的一个知识点,其内部的基本实现原理是每一位面试者都应该掌握的,只有真正地掌握了 HashMap的内部实现原理,面对面试 ...
面试突然问Java多线程底层原理，我哭了！
兄弟们,不要踩坑啊,我原本打算在金九银十之前换份工作,结果出去第一面就被干懵了! 面试官上来就问我了解不了解多线程,我感觉我还可以,我就和他说:必须的! 不过,他直接问了多线程的底层原理,这我都是一知 ...
long 转为string_面试必问 Redis数据结构底层原理String、List篇
点击关注上方"Java大厂面试官",第一时间送达技术干货. 阅读文本大概需要 8 分钟. 前言今天来整理学习下Redis有哪些常用数据结构,都是怎么使用的呢?首先看下全局存储结构 ...
互联网大厂面试必问的JVM底层原理，美团阿里Java程序员晒工资被围观
前言作为同时具备高性能.高可靠和高可扩展性的典型键值数据库,Redis不仅功能强大,而且稳定,理所当然地成为了大型互联网公司的首选. 众多大厂在招聘的时候,不仅会要求面试者能简单地使用Redis,还 ...

要想通过面试，MySQL的Limit子句底层原理你不可不知

文章目录

1.老样子，建个表

2.从sql执行计划看Limit的影响

3. 从server层和存储引擎层分析Limit执行过程

要想通过面试，MySQL的Limit子句底层原理你不可不知相关推荐

最新文章

热门文章