MySQL的LIMIT必须置于语句末尾且仅接受整数，标准写法为LIMIT row_count或LIMIT offset, row_count；OFFSET从0开始，大偏移量会导致全表扫描，应改用游标分页等优化策略，并务必搭配确定性ORDER BY。
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 值本身不能来自未校验的用户输入——必须做范围检查，否则可能触发全表扫描甚至被用于慢查询攻击。
