写 SQL 的时候，大多数开发者都有一个根深蒂固的习惯：如果只需要返回一条记录，一定要加上 LIMIT 1。
这套逻辑看起来天衣无缝——数据库只要找到第一条满足条件的记录，就可以立即停止扫描，不必遍历剩下的几百万行数据，既节省 IO 又降低 CPU 消耗。但现实往往比想象更出人意料。前几天排查线上问题时，遇到了一个非常典型的案例：加了 LIMIT 1，查询反而慢了 50 倍。
这就像你想抄近道走一条小路，结果发现小路堵得水泄不通，比走大路还要慢。
1. 问题现场还原
业务需求很简单：查询某位用户最近的一笔“处理中”的订单。
订单表 orders 大约有 500 万条数据，表中建了两个关键索引：
- idx_user_status
(user_id, status)：用于按用户和状态快速过滤。 - idx_create_time
(create_time)：用于按时间排序。
代码中的 SQL 是这样的：
SELECT id, order_no, amount FROM orders WHERE user_id = 10086 AND status = 1 ORDER BY create_time DESC LIMIT 1;
这条 SQL 上线后立即触发了慢查询报警，耗时高达 2.5 秒。
为了排查原因，我们把 LIMIT 1 去掉，重新执行：
SELECT id, order_no, amount FROM orders WHERE user_id = 10086 AND status = 1 ORDER BY create_time DESC;
结果仅仅用了 50 毫秒。
加 LIMIT 本来是想提升效率，为什么反而变得更慢了呢？
2. 执行计划深度分析
遇到这种反常情况，第一件事就是查看执行计划。对比两条 SQL 的 EXPLAIN 结果，真相立刻浮出水面：
- 不加 LIMIT 时： MySQL 选择了
idx_user_status索引。它先精准定位该用户状态为 1 的订单（只有几十条），然后在内存中排序。由于数据量极少，排序几乎是瞬时完成。 - 加了 LIMIT 后： MySQL 出乎意料地放弃了精准过滤，转而使用
idx_create_time索引。它的逻辑变成了：按时间倒序扫描全表，边扫描边检查是否属于该用户的订单。
为什么优化器会认为第二种方案更优？
这里需要站在 MySQL 优化器的视角来理解。它在做决策时，其实是在计算成本：
- 方案 A（走过滤索引）：先找出所有符合条件的数据，再排序。——缺点：如果匹配的数据很多，排序成本会很高。
- 方案 B（走时间索引 + LIMIT）：既然你只要 1 条数据，而且要求按时间倒序，那就顺着时间索引往回找。——优点：天然有序，无需额外排序。
优化器实际上是在赌——它认为，只要运气不是太差，很快就能碰到一条满足 user_id 和 status 的记录。
问题恰恰出在这个“赌”上。
在这个案例中，用户 10086 是一个老用户，他最近一笔“处理中”的订单，实际上是一年前下的。
于是，MySQL 沿着时间索引，从今天的数据开始往回扫描，扫了昨天、上周、上个月……一直扫了 200 多万行数据，才在去年的记录中找到目标。这就是为什么加了 LIMIT 1 反而变成了全表扫描级的慢查询——优化器的错误决策，把一个本该秒出的查询活生生拖成了马拉松。
3. 解决方案与优化建议
既然知道问题出在优化器选错索引，那么思路就是帮它纠正路径。
方案一：直接使用 FORCE INDEX
既然优化器不清楚，我们就直接告诉它该走哪条路。
SELECT ... FROM orders FORCE INDEX (idx_user_status) ...
这就像在导航中强制指定路线。优点是立竿见影，缺点是代码不够灵活，如果以后索引名变了，这行代码就会报错。
方案二：创建最合适的联合索引
优化器之所以纠结，是因为现有索引无法同时满足“过滤”和“排序”两个需求。
我们可以建立一个联合索引：(user_id, status, create_time)。在这个索引中，数据先按用户和状态聚合，内部再按时间排序。MySQL 只需使用这个索引，既能精准定位，又无需额外排序，这是最完美的解法。
方案三：利用子查询隔离 LIMIT 的影响
如果不想修改表结构，还有一个小技巧：
SELECT * FROM ( SELECT ... FROM orders WHERE user_id = 10086 AND status = 1 ORDER BY create_time DESC) AS tmp LIMIT 1;
通过子查询先找出所有符合条件的数据，此时 MySQL 会乖乖走过滤索引，然后再在外层取 LIMIT 1。这相当于人为切断了 LIMIT 对内层索引选择的干扰。
写在最后
LIMIT 1 确实是一个好习惯，但需要根据实际场景灵活运用。在这个案例中，MySQL 优化器因为过度自信，认为“很快就能找到这一条”，结果在数据分布不均匀的情况下栽了跟头。
下次如果再遇到加了限制条件反而变慢的问题，不妨先用 EXPLAIN 查看执行计划。毕竟，优化器有时候也会做出不靠谱的决定——别太迷信它，该手动检查的时候一定要动手。
