MySQL 的 LIMIT
语法到底怎么写才不翻车
直接说结论：
LIMIT必须放在语句末尾，且只接受整数（或变量），不能是表达式、函数或负数。常见错误是写成
LIMIT 10, OFFSET 20（MySQL 8.0.12+ 才支持这种写法），老版本会报错
ERROR 1064。
标准写法只有两种：
LIMIT row_count：取前 N 行，比如
LIMIT 10
LIMIT offset, row_count：跳过 M 行，取 N 行，比如
LIMIT 20, 10（从第 21 行开始取 10 条）
注意：
offset从 0 开始计数，不是页码。第 3 页（每页 10 条）对应
LIMIT 20, 10，不是
LIMIT 30, 10。
为什么 LIMIT 10000, 20
越往后越慢
MySQL 执行带大
OFFSET的查询时，仍需扫描并丢弃前 10000 行——哪怕你只要最后 20 条。这不是“跳转”，而是“逐行数”。当表有索引但排序字段无覆盖索引时，性能下降更明显。
优化思路不是调
LIMIT参数，而是换策略： 用游标分页（
WHERE id > ? ORDER BY id LIMIT 20），适合按主键/时间递增场景 用延迟关联减少回表：
SELECT * FROM t JOIN (SELECT id FROM t ORDER BY id LIMIT 10000, 20) AS tmp USING(id)业务上限制最大页码（如只允许查前 100 页），避免用户手动输超大 offset
ORDER BY 忘加会出什么问题
LIMIT不加
ORDER BY时，结果顺序不确定。MySQL 可能按插入顺序、主键顺序或存储引擎内部顺序返回，但不保证稳定。同一语句多次执行可能拿到不同行。
尤其在分页场景下，这会导致：
某条记录在第 2 页和第 3 页重复出现 某条记录直接“消失”（被跳过） 前端滚动加载时数据错乱必须搭配确定性排序：
ORDER BY created_at DESC, id DESC（加上
id防止时间相同导致排序不稳定）。
MySQL 8.0+ 的 OFFSET
关键字要不要用
新语法
LIMIT row_count OFFSET offset（如
LIMIT 20 OFFSET 20）语义更清晰，但和传统
LIMIT offset, row_count完全等价，性能无差别。
是否切换取决于团队习惯和兼容性：
如果要兼容 MySQL 5.7 或 MariaDB 10.2 以下，只能用旧写法 如果项目已全面升级，用OFFSET更易读，也方便 ORM 映射（如 SQLAlchemy 的
offset()方法） 注意：某些旧版客户端或中间件（如早期 ProxySQL）可能解析不了新语法
真正容易被忽略的点是：无论用哪种写法，
OFFSET值本身不能来自未校验的用户输入——必须做范围检查，否则可能触发全表扫描甚至被用于慢查询攻击。
