LIMIT无法解决大表卡顿，因其执行时仍需扫描并跳过OFFSET前所有行，尤其OFFSET大时性能断崖下降；真正高效的是游标分页，即用上一页末尾主键值作为WHERE条件（如WHERE id > 123456 LIMIT 10），避免重复扫描。
为什么 LIMIT 不能解决大表查询卡顿
直接加 LIMIT 10 看似能快，但 MySQL 仍要先扫描全表或大量索引页才能定位到“第 N 条之后的记录”，尤其当 OFFSET 很大时（比如 LIMIT 100000, 10），性能会断崖式下降。这不是前端限制数据量的问题，而是服务端执行计划没绕过无效扫描。
- MySQL 不会跳过前 10 万行再读，而是逐行计数、过滤、排序后才取 10 条
-
ORDER BY字段没索引？那连排序都要临时文件 + 文件排序（Using filesort） - 如果
WHERE条件本身走不到索引，LIMIT只是让慢得更隐蔽，不是更快
真正有效的分页替代方案：用游标（cursor-based pagination）
放弃 OFFSET，改用上一页最后一条记录的主键值作为下一页起点，避免重复扫描已跳过的行。
- 适用前提：
ORDER BY id ASC且id是单调递增主键（或带唯一索引的时间戳字段） - 把
SELECT * FROM orders ORDER BY id LIMIT 100000, 10换成：SELECT * FROM orders WHERE id > 123456 ORDER BY id LIMIT 10
- 注意：不能混用
DESC和ASC方向；如果排序字段有重复值，需加二级排序（如ORDER BY created_at, id）确保稳定性 - 客户端必须保存上一页末尾的
id值，不能靠页码计算
LIMIT 在什么场景下确实有用
它只在能配合强过滤条件、且扫描范围可控时才有效——本质是“提前终止”，不是“跳过”。
- 查最新 10 条日志：
SELECT * FROM logs ORDER BY created_at DESC LIMIT 10，只要created_at有索引，就能走索引最右匹配，基本不扫表 - 配合
WHERE缩小范围后再限流：SELECT * FROM users WHERE status = 'active' ORDER BY updated_at DESC LIMIT 20，前提是status和updated_at联合索引存在 - 做存在性检查（非分页）：
SELECT 1 FROM orders WHERE user_id = 123 LIMIT 1，找到一条就停，比COUNT(*)快得多
容易被忽略的底层细节：执行计划和索引覆盖
即使写了 LIMIT，如果 EXPLAIN 显示 type 是 ALL 或 rows 过大，说明根本没走对索引。
- 用
EXPLAIN FORMAT=TREE（8.0+）看实际扫描路径，重点关注rows_examined - 避免
SELECT *：如果只需要id和title，就把它们建在联合索引里，实现“索引覆盖”，避免回表 -
LIMIT对UNION、子查询、GROUP BY后的临时结果无效——这些操作本身已生成完整中间集 - 分区表慎用
LIMIT：若未按分区键过滤，MySQL 可能仍需扫描多个分区
分页卡顿的核心从来不在“返回多少条”，而在“MySQL为了拿到这几十条，到底翻了多少页旧账”。游标分页不是银弹，但它把“跳过 N 行”的成本，从线性降到了常数级——前提是你的排序字段真能当路标用。
