共计 4601 个字符，预计需要花费 12 分钟才能阅读完成。
丸趣 TV 小编给大家分享一下 MySQL 中的 LIMIT 语句有什么用，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
问题
为了故事的顺利发展，我们得先有个表：
CREATE TABLE t (
id INT UNSIGNED NOT NULL AUTO_INCREMENT,
key1 VARCHAR(100),
common_field VARCHAR(100),
PRIMARY KEY (id),
KEY idx_key1 (key1)
) Engine=InnoDB CHARSET=utf8;表 t 包含 3 个列，id 列是主键，key1 列是二级索引列。表中包含 1 万条记录。
当我们执行下边这个语句的时候，是使用二级索引 idx_key1 的：
mysql EXPLAIN SELECT * FROM t ORDER BY key1 LIMIT 1;
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-------+
| 1 | SIMPLE | t | NULL | index | NULL | idx_key1 | 303 | NULL | 1 | 100.00 | NULL |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)这个很好理解，因为在二级索引 idx_key1 中，key1 列是有序的。而查询是要取按照 key1 列排序的第 1 条记录，那 MySQL 只需要从 idx_key1 中获取到第一条二级索引记录，然后直接回表取得完整的记录即可。
但是如果我们把上边语句的 LIMIT 1 换成 LIMIT 5000, 1，则却需要进行全表扫描，并进行 filesort，执行计划如下：
mysql EXPLAIN SELECT * FROM t ORDER BY key1 LIMIT 5000, 1;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
| 1 | SIMPLE | t | NULL | ALL | NULL | NULL | NULL | NULL | 9966 | 100.00 | Using filesort |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
1 row in set, 1 warning (0.00 sec)有的同学就很不理解了：LIMIT 5000, 1 也可以使用二级索引 idx_key1 呀，我们可以先扫描到第 5001 条二级索引记录，对第 5001 条二级索引记录进行回表操作不就好了么，这样的代价肯定比全表扫描 +filesort 强呀。
很遗憾的告诉各位，由于 MySQL 实现上的缺陷，不会出现上述的理想情况，它只会笨笨的去执行全表扫描 +filesort，下边我们唠叨一下到底是咋回事儿。
server 层和存储引擎层
大家都知道，MySQL 内部其实是分为 server 层和存储引擎层的：
server 层负责处理一些通用的事情，诸如连接管理、SQL 语法解析、分析执行计划之类的东西
存储引擎层负责具体的数据存储，诸如数据是存储到文件上还是内存里，具体的存储格式是什么样的之类的。我们现在基本都使用 InnoDB 存储引擎，其他存储引擎使用的非常少了，所以我们也就不涉及其他存储引擎了。
MySQL 中一条 SQL 语句的执行是通过 server 层和存储引擎层的多次交互才能得到最终结果的。比方说下边这个查询：
SELECT * FROM t WHERE key1 a AND key1 b AND common_field != aserver 层会分析到上述语句可以使用下边两种方案执行：
方案一：使用全表扫描
方案二：使用二级索引 idx_key1，此时需要扫描 key1 列值在 (a , b) 之间的全部二级索引记录，并且每条二级索引记录都需要进行回表操作。
server 层会分析上述两个方案哪个成本更低，然后选取成本更低的那个方案作为执行计划。然后就调用存储引擎提供的接口来真正的执行查询了。
这里假设采用方案二，也就是使用二级索引 idx_key1 执行上述查询。那么 server 层和存储引擎层的对话可以如下所示：
server 层：“hey，麻烦去查查 idx_key1 二级索引的 (a , b) 区间的第一条记录，然后把回表后把完整的记录返给我哈”
InnoDB：“收到，这就去查”，然后 InnoDB 就通过 idx_key1 二级索引对应的 B + 树，快速定位到扫描区间 (a , b) 的第一条二级索引记录，然后进行回表，得到完整的聚簇索引记录返回给 server 层。
server 层收到完整的聚簇索引记录后，继续判断 common_field!= a 条件是否成立，如果不成立则舍弃该记录，否则将该记录发送到客户端。然后对存储引擎说：“请把下一条记录给我哈”
小贴士：
此处将记录发送给客户端其实是发送到本地的网络缓冲区，缓冲区大小由 net_buffer_length 控制，默认是 16KB 大小。等缓冲区满了才真正发送网络包到客户端。
InnoDB：“收到，这就去查”。InnoDB 根据记录的 next_record 属性找到 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 t ORDER BY key1 LIMIT 5000, 1;如果使用 idx_key1 执行上述查询，那么 MySQL 会这样处理：
server 层向 InnoDB 要第 1 条记录，InnoDB 从 idx_key1 中获取到第一条二级索引记录，然后进行回表操作得到完整的聚簇索引记录，然后返回给 server 层。server 层准备将其发送给客户端，此时发现还有个 LIMIT 5000, 1 的要求，意味着符合条件的记录中的第 5001 条才可以真正发送给客户端，所以在这里先做个统计，我们假设 server 层维护了一个称作 limit_count 的变量用于统计已经跳过了多少条记录，此时就应该将 limit_count 设置为 1。
server 层再向 InnoDB 要下一条记录，InnoDB 再根据二级索引记录的 next_record 属性找到下一条二级索引记录，再次进行回表得到完整的聚簇索引记录返回给 server 层。server 层在将其发送给客户端的时候发现 limit_count 才是 1，所以就放弃发送到客户端的操作，将 limit_count 加 1，此时 limit_count 变为了 2。
… 重复上述操作
直到 limit_count 等于 5000 的时候，server 层才会真正的将 InnoDB 返回的完整聚簇索引记录发送给客户端。
从上述过程中我们可以看到，由于 MySQL 中是在实际向客户端发送记录前才会去判断 LIMIT 子句是否符合要求，所以如果使用二级索引执行上述查询的话，意味着要进行 5001 次回表操作。server 层在进行执行计划分析的时候会觉得执行这么多次回表的成本太大了，还不如直接全表扫描 +filesort 快呢，所以就选择了后者执行查询。
怎么办？
由于 MySQL 实现 LIMIT 子句的局限性，在处理诸如 LIMIT 5000, 1 这样的语句时就无法通过使用二级索引来加快查询速度了么？其实也不是，只要把上述语句改写成：
SELECT * FROM t, (SELECT id FROM t ORDER BY key1 LIMIT 5000, 1) AS d
WHERE t.id = d.id;这样，SELECT id FROM t ORDER BY key1 LIMIT 5000, 1 作为一个子查询单独存在，由于该子查询的查询列表只有一个 id 列，MySQL 可以通过仅扫描二级索引 idx_key1 执行该子查询，然后再根据子查询中获得到的主键值去表 t 中进行查找。
这样就省去了前 5000 条记录的回表操作，从而大大提升了查询效率！
以上是“MySQL 中的 LIMIT 语句有什么用”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道！
