MySQL中LIMIT用于限制查询结果条数，配合WHERE筛选和ORDER BY排序使用，三者需索引覆盖以保障性能；大数据分页应避免OFFSET，改用游标或覆盖索引。
MySQL 用 LIMIT 限制查询结果条数
直接在 SELECT 语句末尾加 LIMIT 就能控制返回多少行，这是最常用、开销最小的截断方式。
-
LIMIT N：取前 N 行，比如SELECT * FROM users LIMIT 10返回最多 10 条 -
LIMIT M, N：跳过前 M 行，再取 N 行（等价于LIMIT N OFFSET M），适合分页但注意 M 变大时性能会明显下降 - 如果查询本身没加
ORDER BY，LIMIT返回的顺序不保证稳定，生产环境务必配合排序使用
WHERE 是真正的数据筛选起点
LIMIT 只管“拿几条”，真正决定“拿哪些数据”的是 WHERE 子句。它在查询执行早期就过滤行，直接影响扫描量和性能。
- 写法示例：
SELECT name, age FROM users WHERE age >= 18 AND status = 'active' - 避免在
WHERE中对字段用函数（如WHERE YEAR(create_time) = 2023），会导致索引失效 - 字符串比较注意大小写：MySQL 默认校对规则（collation）可能忽略大小写，需要精确匹配时用
BINARY或指定校对规则，例如WHERE name COLLATE utf8mb4_bin = 'Admin'
ORDER BY + LIMIT 组合必须加索引
分页或取 Top-N 场景下，ORDER BY ... LIMIT 看似简单，但没索引支撑时可能全表扫描+文件排序，延迟飙升。
- 例如
SELECT * FROM orders ORDER BY created_at DESC LIMIT 20，必须在created_at上有索引 - 复合排序要匹配索引最左前缀：如果按
(status, created_at)排序，索引也得建在(status, created_at)上才有效 - 用
EXPLAIN检查执行计划，重点关注type是否为range或index，以及Extra里有没有Using filesort
大数据量分页时 OFFSET 的坑
用 LIMIT 10000, 20 跳过前一万行？MySQL 仍要扫描并丢弃这 10000 行，不是“直接跳”。数据越往后，越慢。
- 替代方案：用游标（cursor-based pagination），比如记录上一页最后一条的
id或created_at值，下一页查WHERE id > 12345 LIMIT 20 - 或者改用覆盖索引减少回表，例如只查
id和name，并在(status, id)上建联合索引 - 千万级表慎用
OFFSET分页，前端显示“第 500 页”这种需求，后端最好转成基于条件的滚动加载
实际业务里，WHERE 决定数据集范围，ORDER BY 定义顺序，LIMIT 控制输出量——三者缺一不可，但最容易被忽略的是索引是否覆盖整个链路。
