LIMIT 1 仅在无索引且需确认存在性时有效，如email未建索引的查询；若已走主键、唯一索引或覆盖索引，则无效，且掩盖索引缺失问题。
LIMIT 1 不是万能加速器，它只在特定条件下生效：当查询条件无法利用索引（比如 email 字段没建索引），且你明确知道结果最多一条时，加 LIMIT 1 才有实际价值。否则，它基本不改变性能。
什么时候加 LIMIT 1 真的有用？
核心判断依据是：MySQL 是否必须扫描多行才能确认“就这一条”。常见于以下场景：
- WHERE 条件字段 没有索引，例如
SELECT * FROM user WHERE email = 'a@b.com'（email未建索引） - 查询目的只是“是否存在”或“取任意一条”，比如权限校验、存在性判断：
SELECT 1 FROM order WHERE user_id = 123 LIMIT 1 - 业务逻辑保证唯一性（如唯一约束、业务层已校验），但数据库层面未建索引或索引失效
这时加 LIMIT 1 能让优化器提前终止扫描——找到第一条就停，避免全表扫完。
什么时候加了也白加？
如果查询本身已经能走索引快速定位单行，LIMIT 1 不会带来任何收益，还可能干扰优化器选择执行计划：
- 主键查询：
SELECT * FROM user WHERE id = 123→ 无需LIMIT 1 - 唯一索引字段查询：
SELECT * FROM user WHERE email = 'a@b.com'（email有 UNIQUE 索引）→ 无需LIMIT 1 - 联合索引覆盖查询，且条件能精确命中索引前缀：
SELECT name FROM user WHERE status = 'active' AND created_at > '2025-01-01'（(status, created_at)是复合索引）→ 加LIMIT 1无意义
此时执行计划中 type 是 const 或 ref，说明 MySQL 已经知道只查一行。
容易被忽略的陷阱
很多人以为加了 LIMIT 1 就安全，但实际踩坑点很隐蔽：
-
LIMIT 1不解决根本问题：它掩盖了缺失索引的问题。长期靠它提速，等于把性能债留给未来 - ORM 自动生成 SQL 时可能忽略它，比如 Hibernate 的
findOptionalByXxx()底层未必加LIMIT 1，得看具体方言和配置 - 在
ORDER BY+LIMIT 1场景下，若排序字段无索引，MySQL 仍需先排序全部匹配行再取头一条——LIMIT 1无法跳过排序开销 -
SELECT *+LIMIT 1在宽表（含 TEXT/BLOB）上仍会加载整行数据，不如明确列名 + 覆盖索引更高效
真正该优先做的，永远是检查 EXPLAIN 输出里的 key 和 rows 字段——而不是无脑补 LIMIT 1。
