写SQL的时候，大家都有个固有认知：只查少量数据时，加上LIMIT N能大幅提升效率，毕竟数据库不用扫描全表，找到目标数据就能停止查询，既节省磁盘IO，又减少CPU消耗。
但上周排查线上数据库性能问题时，却遇到了一个反常识的情况：给一条查询加了LIMIT 10，耗时从原本的80毫秒飙升到8秒，慢了整整100倍。这就像本想走捷径抄近路，结果却闯进了死胡同，比走主干道的耗时还多得多。
排查后发现，问题的根源还是出在MySQL优化器的索引选择上，看似合理的查询优化，反而让优化器做出了错误的决策。
- 还原一下现场
这个业务场景很常见：从商品交易表中，查询某个商家近30天内「待发货」的前10笔订单，按支付时间倒序排列，取订单号、支付金额、买家信息。
交易表trade有近800万条数据，是线上核心业务表，表里建了两个核心索引，分别应对不同的查询需求：
• idx_merchant_status：联合索引(merchant_id, status, create_time)，用于按商家、订单状态过滤数据，附带创建时间辅助排序
• idx_pay_time：单列索引(pay_time)，专门用于按支付时间排序查询
业务代码中的SQL语句是这样写的： SELECT trade_no, pay_amount, buyer_info FROM trade WHERE merchant_id = 8888 AND status = 2 AND pay_time >= DATE_SUB(NOW(), INTERVAL 30 DAY) ORDER BY pay_time DESC LIMIT 10; 这条SQL上线后，直接触发了数据库慢查询告警，单条查询耗时稳定在8秒左右，严重影响了接口响应速度。
抱着试一试的心态，我去掉了LIMIT 10，重新执行了一遍查询： SELECT trade_no, pay_amount, buyer_info FROM trade WHERE merchant_id = 8888 AND status = 2 AND pay_time >= DATE_SUB(NOW(), INTERVAL 30 DAY) ORDER BY pay_time DESC; 结果令人意外：这条无限制的查询仅用80毫秒就返回了结果，总共也就20多条符合条件的数据。
同样的查询条件，只是加了一个LIMIT 10，效率为何天差地别？
- Explain分析，揪出问题根源
遇到这种诡异的数据库性能问题，第一步必然是查看执行计划。对比两条SQL的EXPLAIN结果后，问题的真相立刻浮出水面：加了LIMIT后，MySQL优化器选错了索引。
未加LIMIT时：走过滤索引，高效查询
MySQL优化器选择了idx_merchant_status这个联合索引，执行流程非常高效：
-
先通过merchant_id=8888和status=2精准过滤，快速定位到该商家待发货的所有订单；
-
再通过索引中的create_time辅助，结合pay_time的范围条件，筛选出近30天的订单，仅20多条；
-
最后在内存中对这20多条数据按pay_time倒序排序，几乎无性能损耗。
整个过程是精准过滤→少量数据排序，数据处理量极小，自然速度飞快。
加了LIMIT后：走时间索引，全索引扫描
加了LIMIT 10后，MySQL优化器直接放弃了精准的过滤索引，转而选择了idx_pay_time这个单列索引，执行流程完全偏离了最优路径：
-
按pay_time倒序全索引扫描，从最新的支付记录开始遍历；
-
每扫描一条记录，就检查是否满足merchant_id=8888、status=2两个条件；
-
直到找到10条符合所有条件的记录，才停止扫描。
优化器为何会做出错误选择？
站在MySQL优化器的角度，它的决策逻辑是基于成本估算的，核心是做了一道“算术题”：
• 方案A（走过滤索引）：先过滤出所有符合条件的数据，再排序，最后取前10条。优化器认为，若符合条件的数据量很大，排序的成本会极高，性价比低；
• 方案B（走时间索引+LIMIT）：按支付时间倒序扫描，天然有序无需排序，找到10条符合条件的数据就停止，理论上扫描行数极少，成本更低。
优化器在这里其实是赌了一把：它默认符合条件的记录在时间索引中分布均匀，能快速找到目标数据。但现实情况却打了优化器的脸——该商家8888的待发货订单，近30天的支付记录都集中在30天的早期，优化器从最新的支付时间开始扫描，足足扫了300多万行数据，才凑够10条符合条件的记录，直接导致查询超时。
而这一问题的本质，是MySQL优化器的成本估算与实际数据分布不匹配，优化器依赖的统计信息，无法精准感知到数据的局部倾斜情况。
- 多维度解决，从临时修复到长期优化
既然找到了问题根源是优化器选错索引，解决思路就很清晰了：要么强制优化器选择正确的索引，要么优化索引设计，让优化器无需纠结就能做出最优选择，同时补充临时解决方案，适配无法修改表结构的场景。
方法一：临时救急，FORCE INDEX强制指定索引
这是最直接、立竿见影的方法，相当于给MySQL优化器“指定路线”，强制它使用过滤索引idx_merchant_status，避免其做出错误选择。 SELECT trade_no, pay_amount, buyer_info FROM trade FORCE INDEX (idx_merchant_status) WHERE merchant_id = 8888 AND status = 2 AND pay_time >= DATE_SUB(NOW(), INTERVAL 30 DAY) ORDER BY pay_time DESC LIMIT 10; 优点：改造成本极低，只需在SQL中增加索引指定，瞬间解决慢查询问题； 缺点：代码耦合性高，若后续索引名修改、索引删除，这条SQL会直接报错；同时属于“硬编码”方案，无法适配所有场景，仅适合临时救急。
方法二：长期最优，优化联合索引，兼顾过滤与排序
优化器之所以纠结，核心原因是现有索引无法同时满足“精准过滤”和“无需排序”，我们可以重新设计联合索引，让索引完美匹配查询条件，这是从根源上解决问题的方案。
针对本次的查询场景，新建联合索引：idx_merchant_status_paytime (merchant_id, status, pay_time) 这个索引的设计完全遵循联合索引设计原则：
-
先放等值查询字段：merchant_id和status是查询中的等值过滤条件，放在最左侧，保证精准过滤；
-
后放排序/范围字段：pay_time既是范围条件（>=30天前），又是排序字段（DESC），放在等值字段后，让索引天然支持排序，避免filesort；
-
匹配最左前缀原则：查询条件从索引最左侧开始连续匹配，索引利用率100%。
创建该索引后，MySQL优化器会直接选择这个索引，执行流程变为：精准过滤→天然排序→直接取前10条，无需额外排序，也无需全索引扫描，查询效率达到最优。
方法三：无侵入改造，子查询切断LIMIT对索引选择的干扰
如果线上环境无法直接修改表结构（如大表建索引会锁表、业务低峰期未到），可以通过子查询的方式，人为切断LIMIT对优化器索引选择的干扰，适配无侵入改造的场景。 SELECT * FROM ( -- 内层子查询：无LIMIT，优化器会选择过滤索引，精准获取符合条件的数据 SELECT trade_no, pay_amount, buyer_info FROM trade WHERE merchant_id = 8888 AND status = 2 AND pay_time >= DATE_SUB(NOW(), INTERVAL 30 DAY) ORDER BY pay_time DESC ) AS tmp -- 外层查询：仅对少量结果集取前10条 LIMIT 10; 核心原理：内层子查询没有LIMIT约束，优化器会按最优策略选择过滤索引，得到少量符合条件的数据；外层查询仅对这部分少量数据取前10条，几乎无性能损耗。 优点：无需修改表结构，无需强制指定索引，代码兼容性高； 缺点：若内层子查询返回的数据量过大，会有一定的内存开销，但本次场景中仅返回20多条数据，完全无影响。
方法四：辅助优化，更新统计信息，让优化器“精准判断”
本次问题的深层原因之一，是MySQL的统计信息过时，导致优化器对数据分布的判断出现偏差。可以手动更新表的统计信息，让优化器基于最新的数分布做成本估算，减少选错索引的概率。 -- 更新trade表的统计信息，InnoDB引擎会重新采样数据，生成精准的统计信息 ANALYZE TABLE trade; 注意：该方法是辅助优化，无法从根本上解决问题，需配合索引优化一起使用；且ANALYZE TABLE对InnoDB表为轻量操作，不会锁表，可在线执行。
- 扩展思考：哪些场景下，LIMIT可能导致查询变慢？
并非所有加LIMIT的场景都会出问题，结合本次案例和实际生产经验，以下3种场景，加LIMIT后容易触发MySQL优化器的错误选择，导致查询变慢，需要重点关注：
场景1：数据分布严重倾斜，目标数据集中在索引尾部
如本次案例，符合条件的记录并非均匀分布在时间索引中，而是集中在索引的早期/尾部，优化器按索引顺序扫描，需要遍历大量数据才能找到目标记录，LIMIT的“终止扫描”优势完全无法体现。
场景2：查询包含“过滤+排序”，且过滤索引与排序索引分离
当查询同时有多条件过滤和指定字段排序，且过滤用的索引和排序用的索引是两个独立索引时，加LIMIT后，优化器大概率会选择排序索引，放弃过滤索引，因为它会认为“排序后取少量数据成本更低”，却忽略了过滤的精准性。
场景3：低选择性字段作为过滤条件，优化器误判扫描成本
若过滤条件中的字段是低选择性字段（如性别、状态，唯一值少），优化器会认为“通过该字段过滤后的数据量仍很大，排序成本高”，加LIMIT后，会倾向于选择排序索引，而非过滤索引，即使实际过滤后的数据量极小。
写在最后
LIMIT N确实是优化查询的好习惯，能有效减少数据返回量，提升接口响应速度，但它并非“万能良药”，在特定场景下，反而会成为“性能陷阱”。
本次案例的核心启示，不仅是解决“LIMIT导致查询变慢”的问题，更在于掌握MySQL优化器的决策逻辑：优化器并非万能的，它的选择基于成本估算和统计信息，而统计信息可能过时、数据分布可能倾斜，这些都会导致优化器做出错误判断。
作为开发和DBA，在写SQL时，不能依赖“肌肉记忆”，更不能想当然地认为“加了优化语法就一定有效”。遇到数据库性能问题，先执行EXPLAIN看执行计划，再针对性优化，这才是最靠谱的做法。
同时，合理的索引设计才是数据库性能优化的核心，好的索引能让优化器无需纠结，直接做出最优选择，从根源上避免慢查询。设计索引时，务必遵循“等值在前、范围在后，过滤与排序兼顾”的原则，让索引完美匹配查询场景。
最后记住：MySQL优化器是优秀的“辅助工具”，但不是“万能神手”，了解它的短板，才能更好地利用它。
