什么时候必须用 LIMIT 防止全表扫描拖垮查询
当查询条件缺失或索引失效，
SELECT *又没加
LIMIT，MySQL 可能扫完整张百万级表再返回结果——这不仅慢，还可能锁表、占满连接池。常见于管理后台的模糊搜索页、日志表原始数据导出、未加过滤的调试 SQL。 线上接口中
SELECT * FROM user_log WHERE created_at > '2024-01-01'忘加
LIMIT，而该字段无索引 → 扫描 300 万行 开发本地执行
SELECT id, name FROM product查数据，表有 200 万行 → MySQL 客户端卡死或 OOM 分页场景用
OFFSET大值（如
LIMIT 10000, 20）却不加覆盖索引 → 实际扫描 10020 行才返回 20 条
LIMIT 在分页逻辑里的实际写法与陷阱
LIMIT offset, row_count看似简单，但
offset越大性能越差，因为 MySQL 仍需定位并跳过前
offset行。真要支持深分页，得换策略，而不是硬扛。 避免
LIMIT 50000, 20：即使有索引，也要先读取前 50020 行主键再回表 改用游标分页（cursor-based pagination）：基于上一页最后一条的
id做条件，例如
WHERE id > 12345 ORDER BY id LIMIT 20后端 API 默认强制加
LIMIT 100，防止前端传恶意大
limit参数导致 DB 压力飙升
INSERT … SELECT 或子查询里用 LIMIT 控制写入规模
批量插入时若不控量，一次
INSERT INTO t1 SELECT * FROM t2可能锁表几十秒。用
LIMIT分批处理是安全底线。
INSERT INTO archive_log SELECT * FROM log WHERE status = 'done' ORDER BY id LIMIT 10000—— 每次只归档 1 万条，配合事务控制锁粒度 DELETE 场景同理：
DELETE FROM temp_table WHERE processed = 0 LIMIT 500，避免长事务和 binlog 过大 注意：
LIMIT在
UPDATE和
DELETE中有效，但在子查询里直接写
(SELECT ... LIMIT 1)是合法的，可用于取默认值或兜底
ORDER BY + LIMIT 的索引优化关键点
如果写了
ORDER BY created_at DESC LIMIT 10，但
created_at没索引，MySQL 就得排序全部数据再取前 10 条——哪怕表只有 1 万行，也比加索引慢一个数量级。 复合索引顺序很重要：
ORDER BY a ASC, b DESC LIMIT应建
(a, b)索引；若写成
ORDER BY a DESC, b ASC，部分旧版本 MySQL 无法利用该索引
LIMIT 1配合
WHERE时，哪怕没索引也可能走
range访问，但别依赖它 —— 加索引才是确定性优化 EXPLAIN 看执行计划时，重点盯
rows列：如果远大于
LIMIT值，说明排序/过滤没走索引，得调
SELECT id, title FROM article WHERE category_id = 5 AND status = 1 ORDER BY publish_time DESC LIMIT 12;
这条语句在
(category_id, status, publish_time)上有联合索引才能真正高效 —— 否则
ORDER BY会触发 filesort，
LIMIT就只剩“减少网络传输”这点意义了。
