前几天群里有位兄弟抛出一个慢查询案例，SQL 长得很普通：
SELECT * FROM order_log WHERE status = 1 ORDER BY create_time DESC LIMIT 1;他说了一句让我愣了一下的话：这个 SQL 加了 LIMIT 1 之后反而变慢了，把 LIMIT 1 去掉，查询时间直接降下来一大截。
光听描述，这不合理。LIMIT 1 意味着只返回一行，按常理来说，数据库应该更快才对。但实际跑下来，确确实实是“加了限制反而更慢”，而且慢得还不是一星半点。
这个场景我在实际工作里见过不止一次，也帮人排查过不少类似的案例。这篇文章就把这个反直觉的问题彻底拆开，讲讲 LIMIT 1 到底会对执行计划产生什么影响，为什么它会让一个本该变快的查询变成慢查询，以及遇到这类问题该怎么定位、怎么解决。
1. 现象与直觉的错位：返回行数少，不等于扫描行数少
1.1 一个典型的“加 LIMIT 反而变慢”现场
先还原一下那个案例的完整现场。
表结构大致是这样的：
CREATE TABLE order_log ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, status TINYINT NOT NULL, create_time DATETIME NOT NULL, amount DECIMAL(10,2), KEY idx_status (status), KEY idx_create_time (create_time) ) ENGINE=InnoDB;表里有几百万行数据，查询目标是：找到status = 1的订单里，create_time最近的那一条记录。
同事给的原始耗时数据大致是：
- 不加 LIMIT 1：全表返回，耗时约 3 秒。
- 加上 LIMIT 1：只返回一行，耗时反而到了 8 秒以上。
第一次看到这个数据，我第一反应也是“不可能，是不是缓存、是不是其他负载影响”。但复现之后，确实稳定复现。这就不是玄学了，而是优化器在 LIMIT 1 的干扰下，选择了一个从“理论估算”上看很便宜、但实际上非常昂贵的执行路线。
1.2 优化器的赌注：LIMIT 1 之后换了执行路线
要理解这个现象，先得接受一个基本事实：数据库优化器并不是真的把 SQL 跑一遍再选最快方案，它是靠“成本估算模型”来选执行计划的。
在没有 LIMIT 1 的时候，优化器知道：我要把这个查询条件下所有满足条件的行都返回。这个时候它评估的是一个“完整扫描”的总成本，通常会更倾向于选择整体吞吐量最高的方案，比如全表扫描配合过滤，或者走过滤性最好的索引。
加上 LIMIT 1 之后，语义完全变了。优化器心里想的是：“我只需要找到第一条满足条件的行，找到之后就可以直接停下来了。” 这种“提前终止”的可能性，会让优化器更激进去选择某个二级索引，因为它以为可以通过索引快速定位到第一条符合条件的行，然后立刻返回，省掉后面大量的扫描。
问题在于，优化器对“第一条”的预估是建立在统计信息上的，如果统计信息不准、数据分布不均匀，那么它以为的“扫两行就能拿到结果”，实际可能是“扫几十万行、回表几十万次之后才拿到结果”。
这个反直觉现象的本质，就是：LIMIT 1 不是说让查询直接返回第一行，而是让优化器敢于选择一条“可能更快找到第一行”的路线。赌赢了，确实快到飞起；赌输了，就会因为索引回表、随机 IO 等问题，比老老实实全表扫描还慢。
1.3 别被 rows_sent 骗了，要看 rows_examined
排查这类问题时，很多人第一反应是看慢查询日志里的Rows_sent，结果发现只有 1，于是更困惑：只发了一行，为什么慢？
这里必须把一个概念掰开：Rows_sent是最终返回给客户端的行数，Rows_examined是数据库实际扫描过的行数。这两者可以相差非常大。
上面那个案例，实际扫描行数可能到了几十万行，甚至上百万行。LIMIT 1 只是限制了最终返回给用户的行数，它并不限制数据库内部为了“找第一行”而访问了多少数据。
所以排查这种问题，第一个习惯就要改过来：不要看返回了多少行，要看内部扫描了多少行、回表了多少次、排序了多少数据。
2. LIMIT 1 影响优化器决策的三个底层机制
2.1 “提前终止”让优化器敢走偏门
先聊第一个机制：提前终止机会对执行计划选择的影响。
没有 LIMIT 时，优化器评估的是整个查询的完整代价。比如一个范围查询，走二级索引可能需要回表一万次，全表扫描只需要顺序读一遍，那优化器很可能选全表扫描，因为回表是随机 IO，一万次随机 IO 的成本远高于一次顺序扫描。
有了 LIMIT 1，优化器的成本模型会发生偏移。它会额外考虑一个问题：如果扫描到第一条满足条件的行就停下来，总代价会是多少？
问题在于，这个“停下来”的时机是高度不可预测的。如果满足条件的数据在表里分布得比较靠前，那提前终止确实能省下大量时间；如果满足条件的数据非常靠后，或者因为索引结构的原因，需要遍历大量无关数据才能找到第一条，那“提前终止”的收益就没那么大了。
而优化器没法准确预知“第一条满足条件的行到底在哪”，它只能基于统计信息估算。估算偏差一大，就会选错路。
这就是 LIMIT 1 让执行计划走向“偏门”的核心原因——它不是根据实际扫描代价选的，而是根据“赌第一条数据可能出现的位置”选的。
2.2 ORDER BY + LIMIT 1 的组合影响更明显
如果 LIMIT 1 单独出现，影响其实没那么夸张。真正的重灾区是ORDER BY 某字段 + LIMIT 1这种组合，因为 WHERE、ORDER BY、LIMIT 三者叠加，优化器的选择空间更大，选错路的概率也更高。
回到前面的案例。SQL 是：
SELECT * FROM order_log WHERE status = 1 ORDER BY create_time DESC LIMIT 1;这里有两个索引候选：idx_status和idx_create_time。
理论上有一个非常完美的执行方案：用idx_create_time按时间倒序扫描，每扫到一行就检查status = 1，找到第一条满足条件的行就立即返回。因为create_time索引天然有序，完全不需要排序。
但问题是：如果表里status = 1的记录非常少，且都集中在较早的时间段，那这个方案需要倒序扫描很多行才能命中第一条符合条件的记录。比如最后 50 万条记录的 status 都不是 1，就要白白扫 50 万行，每行还要回表检查。
另一个候选方案是走idx_status，先用 status 过滤出所有status = 1的记录（这里再回表、再排序），然后再从中取 create_time 最大的一条。
这两个方案各有各的代价。优化器的成本模型会估算两者的代价，然后选一个“看起来”更低的。一旦统计信息不准、索引基数（cardinality）估算偏了，就会选到实际代价很高、看起来却很低的那条路线。
所以ORDER BY + LIMIT 1这两个功能放在一起，等于变相放大了优化器选错执行计划的概率。
2.3 统计信息失真，放大了判断误差
第三个机制，也是最容易被忽略的：统计信息失真。
MySQL 的优化器做成本估算，依赖的是统计信息。InnoDB 表的数据是不断变化的，统计信息不一定是准的，尤其在一些高频更新的表上。
最常见的失真情况有两种：
第一种，索引基数失真。比如idx_status上status = 1的记录实际有 60 万行，但统计信息里记录的是 100 行。优化器评估走idx_status的成本时，会按 100 行的成本算，当然会觉得这条路很便宜。
第二种，数据分布不均匀。比如 status 只有 0、1、2 三个值，但 90% 的数据都是 status = 1。这种情况下，status = 1 的过滤性极差，走这个索引并没有什么优势，但优化器如果只看“有索引可用”，就可能低估扫描行数。
你可能会问，MySQL 不是会自动做统计信息更新吗？确实会，但 InnoDB 的统计信息更新是采样性质的，而且触发时机不可控。在高并发、大批量写入的场景下，统计信息跟实际数据分布完全脱节，是常有的事。
一旦统计信息失真，LIMIT 1 的“提前终止”优势就成了压垮优化器判断的最后一根稻草。它会更愿意相信“走小索引能快速命中第一条”，然后一头扎进坑里。
3. 一次完整复盘：从复现环境到根因定位
3.1 复现环境：表结构、数据分布、原始 SQL
为了把这问题讲透，我按当时复现的环境重新搭了一遍。
还是那张order_log表，数据规模我控制在 80 万行。故意让数据分布极端一点：
status = 1的记录有约 20 万行status = 2的记录有约 5 万行status = 0的记录有约 55 万行- 最近时间段的 30 万行记录里，status 全部是 0
也就是说，如果按create_time倒序去找第一条status = 1的记录，需要先越过 30 万行正在“当前时间附近”的无效数据，然后才能命中历史数据里的status = 1。
这个分布设计就是为了模拟真实业务里的“热点数据倾斜”：新产生的记录大多是某个状态，老状态的记录分布在中后段。
原始 SQL 就是：
SELECT * FROM order_log WHERE status = 1 ORDER BY create_time DESC LIMIT 1;3.2 加了 LIMIT 1 的执行计划：看起来很美
先看有 LIMIT 1 时的执行计划。
EXPLAIN SELECT * FROM order_log WHERE status = 1 ORDER BY create_time DESC LIMIT 1;输出大致是：
id | table | type | key | rows | Extra 1 | order_log | ref | idx_status | 198342 | Using index condition; Using temporary; Using filesort这里有几件事值得注意。
type是ref，说明优化器选择了idx_status这个二级索引来做等值过滤。rows字段估算扫描了 198342 行，和实际 20 万行比较接近，这个估算其实没离谱。
但 Extra 里面赫然写着Using temporary; Using filesort。这说明走了idx_status之后，拿到的还是按 status 聚合但没有按 create_time 排序的数据，为了拿到ORDER BY create_time DESC LIMIT 1的结果，MySQL 必须把这 20 万行先回表取出来，再做排序，最后取第一条。
而Using index condition说明部分过滤条件下推到了存储引擎，但这里其实帮不上太多忙。
也就是说，这条执行计划实际做的事情是：扫描 20 万行二级索引，回表 20 万次取整行数据，然后对 20 万行做内存或磁盘排序，再取第一条。
从 EXPLAIN 看，rows 才 19.8 万，不算夸张。但真正跑起来，回表 20 万次加上 filesort 的代价，非常可观。
3.3 去掉 LIMIT 1 的执行计划：反而是另一条路
再看去掉 LIMIT 1 之后的情况。注意，这里去掉 LIMIT 1 不是同一个业务语义了，但为了对比执行计划走向，这个对照非常有价值。
EXPLAIN SELECT * FROM order_log WHERE status = 1 ORDER BY create_time DESC;输出大致是：
id | table | type | key | rows | Extra 1 | order_log | ALL | NULL | 798342 | Using where; Using temporary; Using filesort这次优化器直接选了全表扫描，type = ALL，rows估算 79.8 万行，几乎没有用任何索引。
为什么去掉 LIMIT 1 反而选了全表扫描？因为优化器意识到：反正要把全部status = 1的记录都取出来排序并返回，全表扫描的顺序读比二级索引的 20 万次随机回表更划算。全表扫描虽然扫得多，但它是顺序 IO，InnoDB 有预读机制，整体吞吐高。而回表是随机 IO，一次两次不明显，20 万次就是天壤之别。
所以两个执行计划对比下来：
- 有 LIMIT 1：走 idx_status，扫描 20 万行索引 + 回表 20 万次 + 排序。
- 无 LIMIT 1：走全表扫描，扫描 80 万行，过滤后排序。
实际耗时，后者反而比前者快。这完全符合了“加了 LIMIT 1 反而变慢”的诡异现象。
3.4 根因确认：回表行数和排序成本被低估了
到这里，根因基本清晰了。
优化器选择idx_status的直观理由是：status 有索引，走索引过滤行数更少，而且 LIMIT 1 的存在让它觉得只需要处理很少量的数据就能返回。但它没有充分意识到的是，status = 1在表里是一个非常低区分度的值，占了四分之一的行数，而且这 20 万行在create_time上完全无序。
结果就是：用idx_status定位到的 20 万行全部需要回表，然后再对这 20 万行进行文件排序。这个代价远远超过了优化器估算出的“用 idx_status 过滤后立刻可以 LIMIT 1”的预期。
反观全表扫描，虽然扫描行数多，但是顺序读、无回表，配合 InnoDB 的预读机制，整体实际代价反而更低。
我把这两个执行计划的实际耗时放在一起做了个对比，结果更直观：
| 执行计划 | 扫描方式 | 访问行数 | 回表次数 | 排序数据量 | 实测耗时 |
|---|---|---|---|---|---|
| 加 LIMIT 1（走 idx_status） | 二级索引+回表 | 约 20 万行 | 约 20 万次 | 20 万行 | 8.2 秒 |
| 去掉 LIMIT 1（全表扫描） | 全表顺序扫描 | 约 80 万行 | 无 | 20 万行 | 3.1 秒 |
这个表一出来，整个问题就一目了然。LIMIT 1 的锅，本质不在 LIMIT 本身，而是优化器被“提前终止”的可能性带偏了。
4. 解决方案对比与最终落地
4.1 方案一：先更新统计信息，观察是否恢复（治标）
如果你遇到的情况和上面类似，第一个动作不是改 SQL，也不是瞎加索引，而是先确认统计信息是否过期。
执行：
ANALYZE TABLE order_log;然后重新看执行计划。
ANALYZE TABLE会重新采样统计信息，优化器做成本估算时就能拿到相对新鲜的索引基数数据。如果问题是由于统计信息严重滞后导致的，这一步之后执行计划可能就已经变了。
但要注意，这只是治标。如果表本身写入频繁，数据分布持续变化，统计信息很快又会过期。尤其对于status这种取值极少、分布倾斜明显的字段，任何一次大批量写入都可能让统计信息失效。
所以这个方案只适合快速止血，不适合作为长期手段。
4.2 方案二：复合索引，把过滤和排序绑在一起（治本）
最稳妥的长期方案，是给表加一个复合索引，让过滤条件和排序字段同时被索引覆盖。
对于业务 SQL：
SELECT * FROM order_log WHERE status = 1 ORDER BY create_time DESC LIMIT 1;最理想的索引是：
ALTER TABLE order_log ADD INDEX idx_status_create_time (status, create_time DESC);在 MySQL 8.0 里支持降序索引，如果用的是 MySQL 5.7 或更早，可以建升序索引(status, create_time)，然后依赖 InnoDB 的反向索引扫描能力，同样可以走索引有序性来避免 filesort。
加了复合索引后，优化器的选择就简单多了。它可以直接走idx_status_create_time，在索引里先定位到status = 1的分区，然后由于索引本身是有序的，直接从这一组的最后一条记录开始反向取一条，就是create_time最大的那条。
这个方案下，扫描的行数通常只有几行，甚至连回表都可以只做一次（取需要的整行数据）。实测耗时直接降到毫秒级。
这里有个关键要点：复合索引的字段顺序很重要。必须把等值过滤字段（status）放在前面，排序字段（create_time）放在后面。如果顺序反过来，MySQL 无法利用索引同时完成过滤和排序。
4.3 方案三：覆盖索引，彻底消灭回表
如果查询只需要返回少数几个字段，不需要SELECT *，那覆盖索引是更极致的手段。
比如业务只需要user_id、create_time、status三个字段：
SELECT user_id, create_time, status FROM order_log WHERE status = 1 ORDER BY create_time DESC LIMIT 1;这时候可以建：
ALTER TABLE order_log ADD INDEX idx_status_create_time_cover (status, create_time DESC, user_id);走这个索引时，所需字段全部在索引页里就能拿到，连回表都省了。这个方案在数据量大、查询频率高的场景下收益非常明显。
但要注意两个问题：
- 覆盖率索引会占用额外存储空间，尤其表很大时，索引体积会明显增加。
- 索引列越多，写入时维护索引的成本越高，所以不要盲目把所有字段都塞进索引。
覆盖索引不是银弹，它是“查询足够简单、字段足够少”的前提下的优化手段。
4.4 方案四：改写 SQL，躲开优化器的盲区
在某些场景下，索引不能随便加（比如老系统、大表锁表风险高），那可以通过改写 SQL 来帮优化器做决策。
思路一：强制走 create_time 索引，让优化器按时间倒序扫描并过滤 status。
SELECT * FROM order_log FORCE INDEX (idx_create_time) WHERE status = 1 ORDER BY create_time DESC LIMIT 1;这个改写的前提是，你确认status = 1的记录在时间上分布得比较靠前，倒序扫描能很快命中。如果满足条件的记录集中在很老的时间段，这个方案反而更糟，因为它会扫掉大量无效时间段的记录。
思路二：用一个子查询先拿到最大时间，再根据时间取记录。
SELECT * FROM order_log WHERE status = 1 AND create_time = ( SELECT MAX(create_time) FROM order_log WHERE status = 1 ) LIMIT 1;这个写法是把排序问题变成了聚合问题。如果MAX(create_time)走复合索引能快速拿到，整体效率也不错。但要注意，如果status = 1的记录里最大 create_time 对应多行，还需要进一步限定主键等条件。
思路三：保留 LIMIT 1，但用业务侧逻辑替代。比如这个场景的本质是“每个状态的最新一条记录”，这属于典型的分组 Top-N 问题。如果业务允许，可以在应用层缓存每个状态的最新记录 id，定时刷新。数据库侧的复杂排序就能完全绕开。
改写 SQL 的核心原则，是让优化器不用猜。它猜不准的时候，就是你 SQL 写得太含糊、给了它太多“自由发挥”空间的时候。
5. 排查这类问题的工具箱与避坑经验
5.1 EXPLAIN ANALYZE：实测行数才是真相
以前排查慢查询，大家第一反应就是EXPLAIN。但EXPLAIN给出的rows是优化器的估算值，不是实际值。你可以信它，但它经常会骗你。
MySQL 8.0.18 及以上版本提供了EXPLAIN ANALYZE，它会真正执行查询，并输出每个执行步骤的实际行数、实际耗时。
对这类问题，直接跑：
EXPLAIN ANALYZE SELECT * FROM order_log WHERE status = 1 ORDER BY create_time DESC LIMIT 1;输出里会出现类似这样的信息：
-> Limit: 1 row(s) (actual time=8200..8200 rows=1 loops=1) -> Sort: order_log.create_time DESC (actual time=8200..8200 rows=200000 loops=1) -> Index lookup on order_log using idx_status (status=1) (actual time=0.2..7000 rows=200000 loops=1)注意看actual time和rows。这里能直接看到：
- 索引查找实际返回了 20 万行。
- 排序实际排了 20 万行。
- 整个查询实际耗时 8.2 秒。
这就是实锤。EXPLAIN ANALYZE能让你直观看到“优化器预期”和“实际发生”之间的巨大鸿沟，比看一万句理论分析都有用。
5.2 optimizer trace：让优化器交代它的“小心思”
如果EXPLAIN ANALYZE已经确认了现状，但你还是想搞清楚“为什么优化器要选这条路”，那就要用optimizer trace。
MySQL 提供了优化器追踪功能，可以记录优化器做决策的全过程。打开方式很简单：
SET optimizer_trace = 'enabled=on'; SELECT * FROM order_log WHERE status = 1 ORDER BY create_time DESC LIMIT 1; SELECT * FROM information_schema.OPTIMIZER_TRACE;这个输出的信息量非常大，有几十个字段，重点看几个关键部分：
considered_execution_plans：优化器考虑了哪些执行计划。rows_estimation：每个候选索引的行数估算。cost：每个计划的成本估算。chosen：最终选择了哪个计划。
在实际排查中，我一般只看三处：候选索引的顺序、每个索引估算的行数、最终选中的原因。往往一眼就能看到问题所在——比如优化器对某个索引的行数估算只有几千，但实际查询扫了 20 万行。
看完之后记得关掉追踪：
SET optimizer_trace = 'enabled=off';这个功能有性能开销，生产环境不要一直开着。
5.3 慢查询日志：三个指标配合看
在生产环境，你未必能直接连接数据库执行EXPLAIN ANALYZE，那慢查询日志就是第一手资料。
在 MySQL 中开启慢查询日志：
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1;然后去慢查询日志里找那条 SQL，重点看三个字段：
Rows_examined：实际扫描了多少行。Rows_sent：实际返回了多少行。Query_time：总耗时。
如果一个慢查询的Rows_sent只有 1，但Rows_examined高达几十万甚至上百万，那问题基本就锁定在“扫描了大量数据只为了取一行”。再配合多一次EXPLAIN ANALYZE，就能顺藤摸瓜找到执行计划的问题。
另外补充一个习惯：看到慢查询不要只看一次，要多看几次。因为同样的 SQL，在冷热缓存下表现差异巨大。第一次跑得很慢，第二次可能因为数据页已经在内存里，快得飞起。多跑几次取稳定值，判断才靠谱。
5.4 避坑经验与其他容易忽略的情况
聊几个实战中容易踩的坑，都是我自己或身边人实实在在遇到过的。
第一个坑：只看EXPLAIN的type以为是好事。type = ref比type = ALL好看，但不代表它更快。尤其是低区分度索引上，ref可能意味着大量回表。判断执行计划好坏，不能只看访问类型，还要看回表次数、排序规模、实际行数。
第二个坑：加了复合索引后，执行计划没变。这种情况通常是统计信息还没更新，或者 SQL 写法里有隐式类型转换，导致索引失效。比如status是字符型，查询里写成status = 1，优化器会做类型转换，索引就废了。养成习惯，字段类型和查询值类型必须严格匹配。
第三个坑：FORCE INDEX用顺手了，长期不摘。强制索引是排查问题的工具，不是长期方案。今天数据分布适合走 A 索引，明天可能就适合走 B 索引了。长期用FORCE INDEX会让优化器失去弹性，数据量大到一定程度后照样踩坑。正确做法是调好索引，让优化器自己选。
第四个坑：忽略数据分布变化。慢查询是有“季节性”的。月初表里 status = 1 的记录少，走 idx_status 很快；月底积累了 50 万行 status = 1 的记录，同样的 SQL 执行计划还是走 idx_status，但速度已经慢成狗了。定期观察执行计划变化，比出了问题再排查更重要。
还有一个很容易忽略的点：如果查询条件里字段的区分度本身就极低，比如 status 就 0、1、2 三个值，那你加什么单列索引效果都有限。这种字段的正确使用方式是放到复合索引最前面，配合其他高区分度字段或排序字段一起用，而不是单独建索引。
6. 一点个人体会
案例排查完，加了个复合索引，SQL 从 8.2 秒降到 0.01 秒。数据摆在一起的时候，觉得这事挺简单的。但你回头想，真正坑人的地方在于 LIMIT 1 这个关键词自带“优化”光环，所有人第一反应都是“加了 LIMIT 就应该更快”。一旦发现它变慢了，大多数人只会怀疑自己是不是写错了，很少有意识去怀疑优化器的判断。
我个人在实际排查中的体会是：碰到“加了限制反而更慢”的 SQL，先别急着改业务逻辑，也别急着骂优化器，先把有 LIMIT 和没 LIMIT 的执行计划各抓一份出来对比。计划之间的差异，通常就是答案所在。这比猜测和玄学有效一百倍。
最后再分享一个小技巧：当你怀疑一个 SQL 有隐藏问题的时候，试着把它改到“带不带 LIMIT、带不带 ORDER BY”各跑一遍，四份执行计划放在一起看。那些平时看不见的执行计划走向，全都会在这个对比里浮出水面。
如果看完这篇文章，你手头正好有一个“加了 LIMIT 1 反而变慢”的慢查询，现在应该知道第一步做什么了——不是删 LIMIT，而是打开 EXPLAIN ANALYZE，看优化器到底在赌什么。
