做后端开发这几年，SQL里最不起眼又最常用的关键字，LIMIT绝对排得上号。一个LIMIT就能解决数据量大了之后的展示问题，但真正把LIMIT用明白的人其实不多。网上一搜"SQL Limit用法"，出来的大多是"limit 10"、"limit 0, 20"这种抄来抄去的笔记，真到了线上慢查询、分页翻到最后几页卡死的时候，很少有人能说清楚问题出在哪。
这篇文章我就从LIMIT的底层逻辑讲起，把两种写法、分页计算、性能陷阱、和其他数据库的对比一次聊透。不管你是刚接触SQL的新手，还是被线上分页接口折磨过的老手，都能从里面找到能直接用的经验。
1. LIMIT基本语法：两种写法与三个隐藏细节
1.1 两种写法的本质区别
LIMIT在MySQL里有两种标准写法，看起来差不多，实际使用场景略有差异。
-- 写法一：偏移量 + 行数 SELECT * FROM users ORDER BY id LIMIT 10, 20; -- 写法二：行数 + OFFSET SELECT * FROM users ORDER BY id LIMIT 20 OFFSET 10;写法一里，LIMIT 10, 20表示跳过前面10行，从第11行开始取20行。写法二更直观一点，LIMIT 20 OFFSET 10同样是跳过10行取20行，只是把偏移量放到了后面。
从我日常使用的习惯来说，写法一输入更快，但可读性稍差。写法二在代码评审时更友好，因为OFFSET这个关键字把"跳过多少行"这个意图表达得很明确。团队协作的项目里，我会倾向于要求统一使用写法二，减少阅读成本。
1.2 参数行为：正数、负数与超大值
很多人不知道，LIMIT的参数在不同数据库里行为差异很大。MySQL里最值得记住的规则：
LIMIT后的两个参数都必须是整数常量，正负号有讲究；- 第一个参数（偏移量）如果是负数，MySQL会报语法错误；
- 第二个参数（行数）如果是负数，MySQL会返回"所有剩余行"。
-- 返回第11行到最后一行的所有记录 SELECT * FROM users ORDER BY id LIMIT 10, -1;这条冷知识在某些特殊场景很实用。比如你要导出某张表从某个位置往后的全部数据，又懒得先统计总数，直接给行数传个-1就能搞定。
但这里有个坑：同一个语句在不同版本里行为可能不一致。MySQL 8.0仍然支持负数行数表示"取到末尾"，但如果你把代码迁移到PostgreSQL，这个写法直接报错。生产环境里我建议别依赖这类边界行为，规规矩矩写一个足够大的数值或者用其他方式实现更稳妥。
1.3 细节：LIMIT 0、与ORDER BY的搭配
LIMIT 0是个特别有意思的写法，它一个数据都不返回，但SQL语法完全合法。很多人会用EXPLAIN SELECT ... LIMIT 0来快速判断一张表的索引情况，因为LIMIT 0让优化器直接略过数据扫描，执行计划特别干净。
另一个经典场景是快速建表：
CREATE TABLE users_backup AS SELECT * FROM users WHERE 1 = 0;如果你只想复制表结构而不想复制数据，WHERE 1 = 0或者配合LIMIT 0都是常用手段。
LIMIT和ORDER BY是强绑定关系。分页查询如果少了ORDER BY，返回顺序是不确定的。MySQL表数据在InnoDB里默认按主键聚簇存放，但查询走了不同索引时物理顺序就不同了。没有ORDER BY的分页，你第一页看到的记录和第二页的记录之间，完全可能发生重复或者遗漏。
提示：
LIMIT从不过滤数据，它只是切取一段已经排序好的结果集。排序是靠ORDER BY完成的，务必记得两者一起用。
2. 分页场景下的LIMIT：从入门到正确的分页姿势
2.1 三种常见分页计算方式
LIMIT最核心的应用就是分页。页面的第N页换算成SQL里的OFFSET，有几种常见做法，很容易被搞混。
方式一：偏移量从0开始
这是后端开发最常用的约定：
-- 每页20条，第一页 SELECT * FROM articles ORDER BY id LIMIT 20 OFFSET 0; -- 第二页 SELECT * FROM articles ORDER BY id LIMIT 20 OFFSET 20; -- 第N页 SELECT * FROM articles ORDER BY id LIMIT 20 OFFSET (N - 1) * 20;方式二：从当前页最后一条记录的ID继续
-- 第一页 SELECT * FROM articles WHERE id > 0 ORDER BY id LIMIT 20; -- 第二页，传入上一页最后一条ID SELECT * FROM articles WHERE id > 100 ORDER BY id LIMIT 20;这种方式不叫传统分页，叫游标分页或者键集分页，后面的性能章节我会细讲。这里你先记住一个结论：数据量大了之后，方式二比方式一快得多。
实际开发中还有个容易踩的坑：前端展示的页码从1开始，后端计算offset = (page - 1) * size，如果后端误把页码传给了OFFSET，第一页永远显示的是第2条到第21条。这种Bug多半不是SQL写错，而是边界计算没对齐，建议在接口层统一封装分页参数，别让SQL层直接接收前端传值。
2.2 分页与COUNT(*)
分页接口通常要返回"总条数"，这就逼着你在查询数据之外再跑一条SELECT COUNT(*)。
SELECT COUNT(*) FROM articles WHERE status = 1; SELECT * FROM articles WHERE status = 1 ORDER BY id LIMIT 20 OFFSET 0;这两条SQL在数据量大时都会慢，但慢的原因不一样。COUNT(*)需要扫描满足条件的所有记录并计数，而LIMIT的慢更多来自偏移量增大后的回表开销。很多优化方案可以复用索引，却没办法省掉COUNT(*)的成本。
于是有人想了个取巧的办法：用LIMIT估算总数，比如查LIMIT 1000，如果返回了1000条就显示"超过1000条"，否则返回实际条数。这个方案在列表展示场景足够用，能省掉一次大查询的损耗，代价是精确性没了。我的建议是：管理后台这种低频场景老老实实COUNT(*)，C端高并发列表接口再用估算策略。
2.3 排序字段不唯一导致的分页错乱
这个坑我印象很深。早期做订单列表分页时，我用ORDER BY create_time LIMIT 20 OFFSET 0取第一页，用LIMIT 20 OFFSET 20取第二页，结果第二页的第一条数据跟第一页的最后一条重复了。
原因很简单：create_time字段在表里不是唯一的，同秒内可能有几十条订单。数据库的排序只保证create_time这个维度有序，create_time相同的记录之间顺序是不稳定的。第一页取完20条，第二页重新执行查询时，同秒记录的顺序可能已经变了。
解决办法一句话：排序字段必须唯一，至少组合起来唯一。要么直接按主键id排序，要么用ORDER BY create_time DESC, id DESC。主键参与排序之后，每一条记录的位置就完全确定了，分页才不会被重复和遗漏困扰。
我在生产环境的标准做法：所有分页SQL的
ORDER BY一律加上主键兜底。即使业务上只需要按时间排序，也会写成ORDER BY create_time, id。这个习惯帮我省掉了大量"页面数据跳来跳去"的Bug。
3. 分页慢的根源：大偏移量LIMIT的性能瓶颈
3.1 为什么LIMIT 100000, 20会很慢
这是LIMIT经典性能问题。一张表里有2000万条数据，你要取第100001页的20条记录，SQL这么写：
SELECT * FROM articles ORDER BY id LIMIT 100000, 20;你以为数据库只查20条，实际上它做了这样的工作：
- 从第一行开始扫描，找到所有满足条件的记录；
- 按
ORDER BY排序（如果有）； - 从第1行数到第100000行，全部丢弃；
- 留下第100001到第100020行返回。
也就是说，偏移量越大，扫描和丢弃的行越多。即使你有完美的索引，数据库也没法直接"跳"到第100001行，只能一行一行数过去。这个过程的CPU和IO开销是实打实的，不会因为你写了LIMIT就变少。
对比一下：LIMIT 20 OFFSET 0几乎秒开，LIMIT 200000, 20可能要几百毫秒，LIMIT 2000000, 20直接卡死。这种问题在数据量上百万之后就非常明显，如果你负责的是千万级流水表，传统分页撑死翻个几百页就扛不住了。
3.2 方案一：延迟关联
延迟关联是解决大偏移分页最实用的手段之一，思路是先查主键，再查全行数据。
-- 普通写法：慢 SELECT * FROM articles ORDER BY id LIMIT 200000, 20; -- 延迟关联：快 SELECT * FROM articles WHERE id IN ( SELECT id FROM articles ORDER BY id LIMIT 200000, 20 );你可以把它理解成"少搬点东西"。子查询只查id列，一个整型字段在索引里就有，不需要回表读整行数据。MySQL扫描索引拿到20个id之后，再用IN去聚簇索引里精确取这20行的完整数据。
这样做的效率提升来自两个方面：一是索引扫描比全表扫描快得多，二是真正需要搬运的行从"二十万行都被读取再丢弃"变成了"只精确读取20行"。实测在百万级表上，这个改写通常能带来10倍以上的性能提升。
不过要注意：子查询里LIMIT 200000, 20还是会扫描二十万个索引项。也就是说，延迟关联改善了"回表读取"的开销，但没有根治"扫描大量偏移量"的问题。数据量继续膨胀到千万级，这个方案也会衰减。
3.3 方案二：游标分页 / 键集分页
如果说延迟关联是"治标"，游标分页就是治本。它的核心思想是不通过偏移量定位，而是通过上一页最后一条记录的排序值定位。
-- 第一页：取id最大的前20条 SELECT * FROM articles WHERE id > 0 ORDER BY id LIMIT 20; -- 第二页：记住上页最后一条ID=100，直接从100之后取 SELECT * FROM articles WHERE id > 100 ORDER BY id LIMIT 20; -- 第三页 SELECT * FROM articles WHERE id > 300 ORDER BY id LIMIT 20;这个写法为什么快？因为WHERE id > 100直接利用了主键索引的B+树查找能力，数据库能瞬间定位到id=101的位置，然后顺序向后取20条。它面对的扫描量永远只是20条记录的大小，与总数据量无关，与翻到第几页也无
