搞SQL优化的人，几乎都绕不过LIMIT这个词。它看似简单，但在实际项目里，我见过太多把LIMIT n,m和LIMIT n搞混、翻页翻到一半接口超时、查排行榜数据对不上的案例。这两个写法不只是“多了一个逗号”的区别，它们的执行逻辑、SQL优化方式和适用场景完全不一样。这篇文章我就用自己的实际调优经验，把LIMIT的底层逻辑、分页场景下的选型、大偏移量时的性能问题，以及我踩过的一些坑一次讲透。
1. LIMIT 语法拆解：LIMIT n 和 LIMIT n,m 在语义上差了十万八千里
1.1 先搞清楚基础定义
从数据库语法层面看，LIMIT n和LIMIT n,m是两个完全不同的用法。这些写法在 MySQL、PostgreSQL、SQLite 这些支持LIMIT关键字的数据库里，语义是统一的。
| 写法 | 含义 | 等价写法 |
|---|---|---|
LIMIT 10 | 直接返回结果集的前 10 行 | 无（部分数据库支持FETCH FIRST 10 ROWS ONLY） |
LIMIT 10, 5 | 跳过前 10 行，返回第 11 行到第 15 行，共 5 行 | LIMIT 5 OFFSET 10 |
LIMIT 5 OFFSET 10 | 同上，跳过 10 行，返回 5 行 | LIMIT 10, 5 |
这里最重要的一点是：LIMIT后面的第一个数字是偏移量，第二个数字是返回行数。偏移量从 0 开始数。如果你真的想在查询里表达“从第 11 行开始拿 5 行”，应该写LIMIT 10, 5，而不是LIMIT 11, 5。
很多人在分页逻辑里习惯写：
-- page 从 1 开始，pageSize = 10 SELECT * FROM orders ORDER BY create_time DESC LIMIT (page - 1) * pageSize, pageSize;当page = 3、pageSize = 10时，实际执行的 SQL 是LIMIT 20, 10。意思是跳过前 20 条，返回第 21 到第 30 条。这个公式很好用，但它本质上是用“偏移量”去换“页码”，页码越深，偏移量越大，性能隐患越大。
1.2LIMIT n不是LIMIT n,m的特例
有人觉得LIMIT n不就是LIMIT 0, n吗语义上可以这么理解，但绝大多数数据库优化器对LIMIT n的处理方式要激进得多。
举个直观例子：
-- 取最新 10 条订单 SELECT * FROM orders ORDER BY create_time DESC LIMIT 10; -- 取第 10001 条到第 10010 条订单 SELECT * FROM orders ORDER BY create_time DESC LIMIT 10000, 10;第一条 SQL，如果create_time上有索引，数据库可以从索引末端倒序扫描，拿到 10 条就立刻停。第二条 SQL，数据库必须从索引位置开始数，数够 10000 条“无用的行”，再拿接下来的 10 条。这个数偏移量的过程，就是LIMIT n,m慢的本质来源。
我做 SQL 优化时有一条基本准则：能用LIMIT n解决的需求，尽量别写成LIMIT n,m。如果业务确实需要跳页，再考虑分页方案，但要评估好深度分页的风险。
1.3 实际业务里两种写法的典型场景
LIMIT n：热门榜单 TOP 10、最新公告、待处理任务池里的前几条、数据采样、批量拉取少量数据。LIMIT n,m：最经典的网页分页组件，类似“第 X 页 / Y 页”，一次跳转到任意页码的场景。LIMIT m OFFSET n：很多 ORM 框架自动生成的语句，实际等同于LIMIT n,m，不要以为它语法不同就会更高效。
一句话总结：LIMIT n是截取流水的“水龙头”，LIMIT n,m是“先舀走 n 瓢再装 m 瓢”的过程，差别不只是形式上多了一个参数。如果你接下来的优化方案只停留在语法区分，那就太浅了，下一步要关注数据库引擎是怎么执行这些语句的。
2. 数据库执行原理：为什么大偏移量的 LIMIT 会越来越慢
2.1 没有 ORDER BY 时的“假顺序”
先提醒一个最容易被忽略的点：LIMIT本身不保证返回顺序。如果查询里没有ORDER BY，数据库返回的“前 10 行”可能只是存储引擎扫描时最先碰到的 10 行，这个顺序在不同时间、不同执行计划下都可能变化。
所以我在任何生产环境的 SQL 审核里，都要求必须带ORDER BY。一个没有明确排序的LIMIT查询，翻页翻到一半，你很可能看到同一行数据出现在两页里，或者某一行始终没出现过。
2.2 排序能用索引和不能用索引，性能是两个世界
看这条 SQL：
SELECT id, order_no, amount FROM orders WHERE status = 1 ORDER BY create_time DESC LIMIT 20;如果status过滤后的数据量很大，create_time又没有合适索引，MySQL 很可能需要先做一次 filesort——把符合条件的所有行都排序一遍，再截取前 20 行。这种情况下LIMIT能帮你减少网络传输和最终结果集大小，但排序成本依然存在。
如果索引结构是(status, create_time)，那么 MySQL 可以按索引顺序扫描，边扫描边判断status=1，凑满 20 行就停，这时LIMIT对性能是有正向作用的，甚至可以说它改变了执行策略。
2.3 大偏移量的真正开销：读取又丢弃
LIMIT 1000000, 20的慢，是很多人都会掉进去的大坑。虽然你最后只拿到 20 行数据，但数据库为了确认这 20 行的位置，需要扫描、排序、检查前 100 万行，然后全部丢弃。如果再叠加上ORDER BY产生的临时文件，这个开销很容易从毫秒级飙升到秒级甚至分钟级。
我在调优一个后台订单列表时遇到过真实案例：表里 500 万条订单，列表接口翻到第 10000 页左右时，单条 SQL 耗时接近 8 秒。EXPLAIN里显示type=ALL，虽然最终结果只有 10 条，但扫描行数显示是 400 多万。这种“取样极少、扫描极多”的现象，是深度分页的典型特征。
2.4 跨数据库差异：LIMIT 不是所有数据库都有
| 数据库 | 取前 N 行写法 | 分页（跳过+取回）写法 |
|---|---|---|
| MySQL | LIMIT n | LIMIT offset, count或LIMIT count OFFSET offset |
| PostgreSQL | LIMIT n | LIMIT count OFFSET offset |
| SQLite | LIMIT n | LIMIT count OFFSET offset |
| SQL Server 2012+ | SELECT TOP n ... | ORDER BY ... OFFSET offset ROWS FETCH NEXT count ROWS ONLY |
| SQL Server 2008 | SELECT TOP n ... | 用ROW_NUMBER() OVER(ORDER BY ...)嵌套子查询 |
| Oracle 12c+ | FETCH FIRST n ROWS ONLY | OFFSET offset ROWS FETCH NEXT count ROWS ONLY |
| Oracle 11g | ROWNUM <= n | 子查询套一层ROWNUM |
比如 SQL Server 用OFFSET-FETCH时，要求必须带ORDER BY，否则直接报错；Oracle 11g 及更早版本没有OFFSET，只能通过解析ROWNUM和子查询来实现，写法上很绕。如果你想做通用性强的数据访问层，尽量不要只用 MySQL 思维去套其他数据库。
2.5 理解查询计划
对于 MySQL 用户，遇到LIMIT性能问题时，第一时间执行：
EXPLAIN SELECT * FROM orders ORDER BY create_time DESC LIMIT 100000, 20;重点关注三列：
type：如果从const、ref变成ALL，说明没走索引，要大改。rows：优化器预估的需要扫描行数，这里是性能问题的风向标。Extra：出现Using filesort时，说明排序没利用上索引，是有优化空间的信号。
大偏移量场景下，rows常常会达到几十万甚至上百万，这就是慢的直接证据。
3. 项目里怎么选：LIMIT n 和 LIMIT n,m 不能拍脑袋决定
3.1 取前 N 条数据时，无脑用 LIMIT n
业务上但凡要的是“最热、最新、最近的若干条”，直接写LIMIT n就行。这种场景尽可能让排序字段走索引，让数据库快速拿到前几条就终止。
例如：
-- 排行榜：取销量前 10 的商品 SELECT goods_id, goods_name, sales FROM goods ORDER BY sales DESC LIMIT 10;如果能给sales建一个二级索引，这个查询在 MySQL 里可以做到非常快，因为索引本身就是有序的，引擎扫描索引就能直接输出前 10 条。
3.2 传统分页组件，用 LIMIT n,m 但要有边界
网站底部的第 1、2、3……页翻页按钮，天然需要“跳到任意页”，这时候LIMIT n,m无法回避。关键是要控制页码上限。
我参与过的后台管理系统里，通常会在条件查询后拼出：
SELECT * FROM operation_log WHERE biz_type = 'refund' ORDER BY log_id DESC LIMIT 20, 10;这种写法在数据量几十万以内、用户翻页不超过几百页时，其实问题不大。但如果放任用户一直翻到第 10 万页，那就是在给数据库上刑。
3.3 滚动加载、上一页/下一页场景，优先用游标
App 的“上拉加载更多”、网页的“加载更多按钮”、搜索结果的“下一页”，这些场景都不需要也不应该直接跳到第 N 页。前端只需要告诉我“当前列表最后一条数据的 id 是什么”，我就可以写成：
SELECT * FROM operation_log WHERE log_id < ?last_log_id AND biz_type = 'refund' ORDER BY log_id DESC LIMIT 10;这就是所谓键集分页，也叫游标分页。它和LIMIT n,m最大的区别是：它是用一个稳定的条件（比如主键 id）来划定边界，而不是靠偏移量去数位置。即使前面新增了几万条数据，只要当前游标不变，下一页的结果依然稳定，不会因为新数据插入导致重复或漏掉。
我用这个方案优化过很多滚动列表，SQL 响应时间无论翻到多深，都是几毫秒到几十毫秒，和“翻到第 100 页”相比有数量级上的差距。
3.4 排序字段必须唯一，否则翻页会乱
无论你最后选LIMIT n还是LIMIT n,m，ORDER BY字段都建议用唯一键，或者用“非唯一排序字段 + 主键”的组合。原因很简单：如果排序字段有大量并列值，比如按status排序，那么同一行可能一会儿排在第 2 位，一会儿排在第 3 位，翻页必然会出现脏数据。
我常用的写法是：
SELECT * FROM orders ORDER BY create_time DESC, id DESC LIMIT 20;把id作为第二排序字段，等于给每个排序位置上了“锚点”，保证结果顺序是确定性的。这个经验在几乎任何分页场景都通用。
4. 大偏移量 LIMIT 的 4 个优化方案：不是只有延迟关联一条路
4.1 方案一：延迟关联，先取主键再回表
这个方案尤其适合 MySQL。核心思路是：先用覆盖索引把主键查出来，避免在子查询阶段就回表带出所有字段，再用主键关联原表，只回表拿需要的行。
-- 原写法 SELECT * FROM orders ORDER BY create_time DESC, id DESC LIMIT 100000, 10; -- 延迟关联优化 SELECT o.* FROM orders o INNER JOIN ( SELECT id FROM orders ORDER BY create_time DESC, id DESC LIMIT 100000, 10 ) t ON o.id = t.id ORDER BY o.create_time DESC, o.id DESC;子查询里只查id，如果(create_time, id)能覆盖这个排序条件，MySQL 就不需要在子查询阶段访问聚簇索引里的所有字段。外层再按主键回表，只取 10 条真实数据，成本大大降低。我把一个百万级订单表翻页到深处时，用这个方案能把响应时间从 2 秒左右降到几十毫秒。
4.2 方案二：游标/键集分页，彻底抛弃偏移量
对于“下一页”类场景，最干净的方案是不要用页码，而是用上一页最后一条数据的定位字段。
-- 第一页 SELECT * FROM orders WHERE status = 1 ORDER BY id DESC LIMIT 10; -- 第二页：从上一页最后一条 id 继续 SELECT * FROM orders WHERE status = 1 AND id < ?last_seen_id ORDER BY id DESC LIMIT 10;这里id < ?last_seen_id可以很好地利用主键索引，每次查询只需要定位到指定游标，然后向后扫描 10 条。无论整个表有多大，只要游标之前的行数不影响本次查询，性能就是稳定的。
它的缺点是用户没法直接跳到第 50 页，也不适合做任意跳页的分页组件。但如果你的产品是无限流、朋友圈、订单流，这个方案基本是首选。
4.3 方案三：尽可能使用覆盖索引消除回表
有时候业务只需要某几个字段，那就别SELECT *，可以把需要的字段和排序字段一起建进索引。
-- 如果只是查看 id、order_no、amount SELECT id, order_no, amount FROM orders WHERE status = 1 ORDER BY id DESC LIMIT 100000, 10;如果索引是(status, id, order_no, amount)，整个查询都可以直接在索引上完成，连回表都省了。实际优化时，我通常会在 EXPLAIN 的Extra里看到Using index，就说明是覆盖索引，这种查询即使偏移量大一些，性能也不会太差。
不过覆盖索引不是越多越好，索引字段过多会增加写入成本和存储空间。我只建议针对高频查询做精准覆盖。
4.4 方案四：从产品层面限制“无限翻页”
很多深度分页问题，其实不需要从 SQL 层面解决，产品上就能化解。例如搜索引擎的“找第 100000 页”没有实际意义，后台系统也可以限制用户只能查看前 5000 条数据，超过就提示使用条件筛选或导出。这样既保证核心体验，也保护数据库。
我之前在数据中台做过一个列表，用户经常为了找一条历史数据不停往后翻，后来我在前端加了一个提示：“筛选条件下最多返回前 5000 条数据，如需全量数据请使用导出功能”，数据库压力立刻降下来不少。SQL 优化永远不只有调 SQL 这一步，改交互也是一种有效的优化手段。
5. 实验对比：同一张表，不同 LIMIT 写法的性能到底差多少
5.1 测试环境准备
我用的测试环境是 MySQL 8.0，InnoDB 存储引擎，一张 120 万行的订单表。表结构简化如下：
CREATE TABLE `orders` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_no` varchar(32) DEFAULT NULL, `amount` decimal(10,2) DEFAULT NULL, `create_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_create_time` (`create_time`) ) ENGINE=InnoDB;数据是按时间顺序插入的，create_time上有索引，但真实查询里还要做排序，所以最终执行计划和生产环境保持一致。
5.2 对比测试结果
| 写法 | SQL 示例 | 耗时（多次采样取中位值） | 大致扫描行数 |
|---|---|---|---|
浅层LIMIT n | SELECT * FROM orders ORDER BY create_time DESC LIMIT 10 | 几毫秒 | 10 |
普通LIMIT n,m前 100 页 | SELECT * FROM orders ORDER BY create_time DESC LIMIT 1000, 20 | 约 20ms | 1020 |
普通LIMIT n,m深度 | SELECT * FROM orders ORDER BY create_time DESC LIMIT 1000000, 20 | 约 600ms~1s | 约 100 万 |
| 延迟关联 | SELECT * FROM orders o INNER JOIN (SELECT id FROM orders ORDER BY create_time DESC LIMIT 1000000, 20) t ON o.id=t.id | 约 40ms | 约 100 万（索引扫描） + 20 次回表 |
| 游标分页 | SELECT * FROM orders WHERE create_time < ?last_time ORDER BY create_time DESC LIMIT 20 | 几毫秒 | 约 20 |
这个结果只能说明趋势，不能照搬到所有环境。数据分布、缓存命中、并发量、服务器配置都会影响具体数字，但核心结论是稳定的：
LIMIT n,m在浅层时性能不错，偏移量一上来就会恶化。- 延迟关联能够大幅度减少回表成本，但前提是子查询能先走索引。
- 游标分页是几个方案里最抗压的，因为它根本没有“偏移量”这个概念。
5.3 为什么延迟关联在这个测试里没慢多少
很多人担心子查询里LIMIT 1000000, 20还是有偏移量，该扫的索引行还是得扫。确实如此，索引扫描本身很快，一百多万行在内存里并不算多，真正拖垮性能的往往是回表。子查询只拿id，让 MySQL 省掉了 100 万次聚簇索引回表动作，所以总时间大幅下降。
如果业务要求必须要页码分页，我就用这个方案兜底，成效很明显。但要提醒一点，子查询里如果还要加很多WHERE条件，优化器未必会走理想索引，建议提前用EXPLAIN验证。
6. 实战避坑：LIMIT 相关的 7 个常见坑和排查方法
6.1 偏移量从 0 开始，前端页码从 1 开始
前端传过来的页码page通常是 1 起步。后端如果忘了offset = (page - 1) * pageSize，直接写LIMIT page, pageSize，第一页变成第二页，第二页变成第三页，数据会整页错位，而且非常隐蔽。
我的排查习惯是：先把前端参数打出来，确认page = 1时实际 SQL 是LIMIT 0, 20而不是LIMIT 1, 20。这个低级错误，出现频率真的很高。
6.2 LIMIT 前不写 ORDER BY，等于随机返回
这个问题不止是分页会出现，连取最新数据也会中招。我见过不少项目用SELECT * FROM table LIMIT 10想拿“某几条数据”，结果数据和预期完全对不上。没有ORDER BY的 SQL，执行计划一变，结果就可能变。所以 LIMIT 的正确标配是ORDER BY，而且最好是唯一排序。
6.3 别把 LIMIT n,m 理解成“取第 n 条到第 m 条”
有同事问我“查第 10 条到第 20 条怎么写”，结果写了LIMIT 10, 20。这是很常见的误解。LIMIT 10, 20并不是取第 10 条到第 20 条，而是跳过 10 条，连续取 20 条。真要取第 10 条到第 20 条，应该是LIMIT 9, 11。遇到这种需求，先反应过来自己是“想去第几行”还是“想去第几条”，再写偏移量。
6.4 大 offset 导致接口超时后，下意识加更多索引
看到大 offset 慢，第一反应不该是加索引，而是先确认慢在哪里。可以分两步：
-- 第一步：只看主键 SELECT id FROM table ORDER BY create_time DESC LIMIT 1000000, 20; -- 第二步：带全字段 SELECT * FROM table ORDER BY create_time DESC LIMIT 1000000, 20;如果第一步很快、第二步很慢，说明问题在回表，延迟关联或覆盖索引能帮上忙；如果第一步就慢，说明排序和索引结构本身有问题，需要重新审视ORDER BY字段和WHERE条件的索引组合。
6.5 SQL Server 中 OFFSET-FETCH 必须配 ORDER BY
从 MySQL 转 SQL Server 的人，很容易在这踩坑：SQL Server 使用OFFSET-FETCH时，如果没写ORDER BY，直接报错。这是语法层面的强制要求。即使LIMIT 10这种“取前 10 条”的写法，在 SQL Server 里也不是直接套用，而是写成SELECT TOP 10 ...。跨数据库迁移时，我一般会先用 ORM 的方言隔离，避免 SQL 硬编码。
6.6 分页接口里频繁执行 COUNT(*) 拖垮数据库
传统分页组件往往需要在查询数据前先算总数，生成“共 10000 条 / 1000 页”这类文案。真实的接口里，一次页面请求经常变成：
SELECT COUNT(*) FROM orders WHERE status = 1; -- 很慢 SELECT * FROM orders WHERE status = 1 ORDER BY id DESC LIMIT 20, 10; -- 也慢两个大查询叠加，数据库很容易被打挂。我建议对非核心列表做简化，不显示总页数，或者把总数缓存起来，设置 30 秒到几分钟的有效期。分页列表的实时总数没那么重要，不要让一个统计数据拖垮核心链路。
6.7 LIMIT 参数要预编译，别直接拼字符串
虽然 LIMIT 后面的参数不是明显的 SQL 注入风险点，但如果不加参数校验，前端传一个负数或超大数字进来，会造成数据库异常。更好习惯是用 JDBCPreparedStatement、MyBatis#{}这类预编译方式，同时服务端限制pageSize的最大值，比如不能超过 100，防止有人恶意拉全表。
7. 我个人的收尾建议
优化过这么多 SQL 之后，我对 LIMIT 的感受很简单：它不是语法难题，而是场景选择题。能确定边界就用游标分页，业务必须跳页码就用延迟关联兜底，实在不行限制页面深度。在我现在的项目里，团队约定“凡是分页接口，默认禁止超过 5000 的偏移量”，超过时要么强制走筛选条件，要么用游标。这个约定看起来粗暴，但实际效果很好，从源头避免了一大批慢 SQL。如果你正在为翻页慢发愁，建议先别急着加机器，先把自己所有的LIMIT n,m翻出来看一眼，大概率能找到突破口。
