MySQL中LIMIT 10必须配合ORDER BY才能保证结果稳定，因为无排序时行序不固定，多次执行可能返回不同记录；偏移量从0开始，大偏移量性能差，推荐游标分页替代。
LIMIT 10 是最直接有效的方式，但必须配合 ORDER BY 才能保证结果稳定可预期
为什么不能只写 SELECT * FROM table LIMIT 10
MySQL 不保证无 ORDER BY 时的行返回顺序。同一语句多次执行可能返回不同 10 行，尤其在表有并发写入、使用 InnoDB 引擎、或执行过 OPTIMIZE TABLE 后。这不是 bug，而是 SQL 标准允许的行为。
常见错误现象：SELECT * FROM orders LIMIT 10 每次查出的“最新订单”都不一样；导出数据时漏掉本该排前的记录。
实操建议：
- 始终搭配明确的排序字段，例如按时间戳或主键降序：
SELECT * FROM orders ORDER BY created_at DESC LIMIT 10 - 若需“插入顺序”的前 10 行，且表有自增主键
id，用ORDER BY id ASC LIMIT 10（前提是未手动指定id） - 避免依赖
ORDER BY RAND()配合LIMIT 10做随机抽样——大数据量下性能极差
LIMIT 的偏移量写法：从第 21 行开始取 10 行
语法是 LIMIT offset, row_count 或等价的 LIMIT row_count OFFSET offset。注意：offset 从 0 开始计数。
使用场景：
- 分页：第 3 页（每页 10 条）对应
LIMIT 20, 10 - 跳过前 N 条做采样分析，如
SELECT * FROM logs ORDER BY ts DESC LIMIT 1000, 10
容易踩的坑：
- 大 offset 性能陡降：MySQL 仍需扫描前
offset + row_count行。例如LIMIT 100000, 10会跳过 10 万行再取 10 行，索引可能失效 - 推荐替代方案：用游标分页（cursor-based pagination），基于上一页最后一条的
id或created_at值做条件查询，例如WHERE id > 12345 ORDER BY id LIMIT 10
在子查询或视图中使用 LIMIT 的限制
MySQL 8.0+ 允许在派生表（subquery in FROM）中直接用 LIMIT，但早期版本（如 5.7）会报错 This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'。
典型错误写法（5.7 及更早）：
SELECT * FROM (SELECT * FROM users ORDER BY reg_time DESC LIMIT 10) AS t WHERE status = 'active';
解决方案：
- 升级到 MySQL 8.0+，该语法已支持
- 改用临时表或 CTE（MySQL 8.0+）：
WITH top_users AS (SELECT * FROM users ORDER BY reg_time DESC LIMIT 10) SELECT * FROM top_users WHERE status = 'active'; - 若必须兼容老版本，先查出 ID 列表再 JOIN，例如：
SELECT u.* FROM users u INNER JOIN (SELECT id FROM users ORDER BY reg_time DESC LIMIT 10) t ON u.id = t.id WHERE u.status = 'active';
真正关键的不是“怎么写 LIMIT”，而是想清楚你要的“前 10 行”到底依据什么逻辑定义——时间？主键？业务权重？一旦排序依据模糊，LIMIT 就成了不可靠的幻影操作。
