MySQL中LIMIT语句的基本用法是限制查询返回行数，有两种语法：LIMIT count（取前count行）和LIMIT offset, count（跳过offset行后取count行），其中offset从0开始、必须为非负整数，count为要返回的行数；分页时必须配合ORDER BY确保结果稳定，大offset会导致性能急剧下降。
MySQL中LIMIT语句的基本用法和参数含义
LIMIT 是 MySQL 中控制结果集行数的唯一标准方式，它不依赖索引或排序，只作用于最终输出。语法有两种形式：LIMIT offset, count 和 LIMIT count。前者常用于分页，后者适合取前 N 条数据。
注意：offset 从 0 开始计数，不是页码；count 是要返回的行数，不是上限值。比如 LIMIT 20, 10 表示跳过前 20 行，取接下来的 10 行 —— 这对应第 3 页（每页 10 条）。
- 如果只写
LIMIT 10，等价于LIMIT 0,10 -
offset必须是非负整数，不能是变量或表达式（除非在预处理语句中） - 当
count为 0 时，查询返回空结果集，但依然会执行 WHERE 和 ORDER BY
分页时为什么必须配合ORDER BY使用
没有 ORDER BY 的 LIMIT 分页是不可靠的。MySQL 不保证无序查询的行物理顺序稳定，尤其在有并发写入、主从同步延迟或优化器选择不同执行计划时，同一条 LIMIT 20,10 可能在两次执行中返回不同记录。
真正安全的分页写法必须带确定性排序：
SELECT * FROM users ORDER BY id ASC LIMIT 20, 10;
- 优先用主键或唯一且非空的索引列排序，避免
ORDER BY RAND()或ORDER BY created_at DESC（若该字段有重复值，排序不稳定） - 如果业务要求按时间倒序分页，建议联合主键：如
ORDER BY created_at DESC, id DESC，确保相同时间戳也能稳定排序 - 不要依赖“自然顺序”或“插入顺序”，InnoDB 表没有这种保证
LIMIT分页在大数据量下的性能陷阱
当 offset 很大（例如 LIMIT 1000000, 20），MySQL 仍需扫描并丢弃前 100 万行，I/O 和 CPU 开销陡增，响应可能从毫秒级变为秒级。
- 这不是
LIMIT的 bug，而是其设计逻辑决定的：它在 server 层截断结果，而非引擎层跳过 - 替代方案不是“优化 LIMIT”，而是改用游标分页（cursor-based pagination）：用上一页最后一条的
id做条件，例如WHERE id > 123456 ORDER BY id LIMIT 20 - 如果必须用偏移分页，确保
ORDER BY字段上有高效索引；否则即使加了索引，filesort也可能拖慢查询
在应用程序中计算LIMIT参数的常见错误
后端代码里把页码直接乘以每页条数，却不校验边界，容易触发 SQL 错误或越界返回空数据。
- 页码从 1 开始时，
offset = (page - 1) * page_size，但需检查page是否 ≤ 0 或非整数 - 数据库不校验
offset是否超出总行数，LIMIT 9999999, 10会安静地返回空结果，前端可能误判为“无数据”而非“已到最后一页” - 更健壮的做法是先查总数（
SELECT COUNT(*)），或用SQL_CALC_FOUND_ROWS（MySQL 8.0 已废弃，不推荐） - 实际项目中，建议限制最大可访问页码（如 ≤ 1000），或对超大 offset 自动降级为 cursor 分页
真正难的不是写出 LIMIT，而是在高并发、大数据、多实例环境下让分页行为可预期、可监控、可退化。ORDER BY 的稳定性、offset 的爆炸性成本、应用层的边界处理，三者缺一不可。
