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控制输出量——三者缺一不可，但最容易被忽略的是索引是否覆盖整个链路。
