必须用LIMIT防止全表扫描拖垮查询：当查询条件缺失或索引失效、SELECT *未加LIMIT时，MySQL可能扫描百万级表，导致慢查询、锁表、连接池耗尽；常见于管理后台模糊搜索、日志导出、调试SQL等场景。
什么时候必须用 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 就只剩“减少网络传输”这点意义了。
