MySQL中LIMIT用于限制返回行数，不加OFFSET时直接取前N条；必须配合ORDER BY保证结果稳定；OFFSET过大导致性能骤降，应改用游标分页等优化方案。
MySQL 用 LIMIT 控制返回行数，不加 OFFSET 最常用
直接在 SELECT 语句末尾加 LIMIT N 就能只取前 N 条记录，比如查用户表前 5 条：
SELECT * FROM users LIMIT 5;这是最轻量、最常被用的分页起点。注意：MySQL 默认不保证顺序，如果没写
ORDER BY，LIMIT 5 每次可能返回不同行——不是 bug，是未定义行为。
LIMIT M, N 和 LIMIT N OFFSET M 效果一样，但后者更可读
两种写法都表示“跳过前 M 行，取接下来的 N 行”。例如跳过前 20 条查第 21–30 条：
SELECT * FROM orders ORDER BY created_at DESC LIMIT 10 OFFSET 20;或等价写法：
SELECT * FROM orders ORDER BY created_at DESC LIMIT 20, 10;推荐用
LIMIT N OFFSET M，因为参数含义更直观；LIMIT M, N 容易把两个数字顺序搞反（M 是 offset，N 是 count），尤其在动态拼 SQL 时容易出错。
大数据量下 OFFSET 越大越慢，不是语法问题而是执行逻辑
当 OFFSET 达到几十万甚至百万级，MySQL 仍需扫描并丢弃前面所有行，I/O 和 CPU 开销陡增。比如：
SELECT * FROM logs ORDER BY id LIMIT 10 OFFSET 1000000;实际会读取 1000010 行再扔掉前 1000000 行。这不是写法错误，而是 MySQL 的执行机制决定的。替代方案包括：
- 用上一页最后一条记录的主键值做条件（游标分页），如
WHERE id > 1234567 ORDER BY id LIMIT 10 - 对高频分页字段加覆盖索引，减少回表
- 业务上限制最大翻页深度（如禁止跳转到第 1000 页）
ORDER BY 必须和 LIMIT 配合使用，否则分页结果不可靠
LIMIT 本身不改变排序逻辑，它只是截断结果集。如果没有 ORDER BY，MySQL 可能按插入顺序、主键顺序、甚至存储引擎内部结构返回数据，每次查询结果都可能不同。尤其是 InnoDB 表，无序查询 + LIMIT 在并发写入场景下极易出现漏数据或重复数据。务必写成：
SELECT id, name FROM products WHERE status = 1 ORDER BY id ASC LIMIT 20;而不是省略
ORDER BY。
真正麻烦的从来不是语法怎么写，而是当 OFFSET 超过十万级后，你才发现 LIMIT 不是“跳过”，而是“硬扫”。这时候改 SQL 不如先看执行计划，再想数据访问模式是否合理。
