这个问题的核心是MySQL优化器在处理ORDER BY mailing LIMIT 1时，选择了一个看似高效但实际完全不适合当前场景的执行计划，咱们来一步步拆解原因：

1. 不同查询的执行逻辑对比 #

先看你的几个查询的执行路径差异：

• 基础查询（无ORDER BY、无LIMIT）：MySQL使用section_CS索引，快速定位到约5000条section=210874的记录，然后逐一过滤token='XFRA1NMDU9XY'的条件，因为结果为0行，遍历完这5000条就结束，耗时0.094秒很合理。
• 带LIMIT 1（无ORDER BY）：同样走section_CS索引，遍历5000条符合section条件的记录找匹配的token，因为没找到，遍历完就返回，耗时0.063秒也正常。
• 带ORDER BY（无LIMIT）：还是走section_CS索引拿到5000条记录，然后在内存中对mailing字段排序（5000条数据量很小，排序成本极低），最后返回0行，耗时0.125秒。
• 带ORDER BY + LIMIT 1：这里出问题了！MySQL优化器选择了mailing_CS索引，它的逻辑是：“如果我按mailing的顺序遍历表，找到第一个符合section=210874且token='XFRA1NMDU9XY'的记录，就能直接返回，不用做排序，这样成本更低”。但现实是没有符合条件的记录，所以MySQL不得不遍历整个mailing_CS索引对应的200万条记录，每条都检查section和token条件，直到遍历完所有数据才确定没有匹配项，这就是耗时飙升到45秒甚至更久的原因。

2. 优化器为什么会选错索引？ #

MySQL优化器做决策时，会基于表的统计信息（比如索引基数、过滤条件的选择性）估算不同执行计划的成本：

• 对于ORDER BY mailing LIMIT 1，优化器认为：走mailing_CS索引可以避免排序操作，而且LIMIT 1意味着只要找到第一条匹配的就结束，理论上成本更低。
• 但它忽略了两个关键问题：
  • token字段没有索引，优化器无法准确估算token='XFRA1NMDU9XY'这个条件的过滤效率；
  • 实际上没有符合所有条件的记录，导致它不得不遍历整个索引，而不是快速找到匹配项。

3. 解决方法 #

针对这个场景，有几种高效的解决方案：

• 创建针对性的联合索引：创建包含section、token、mailing的联合索引：

  CREATE INDEX idx_section_token_mailing ON mydata.mytable(section, token, mailing);
  

  这个索引可以让MySQL快速定位到section=210874且token='XFRA1NMDU9XY'的记录，同时这些记录已经按mailing排序好了，直接取第一条（或确认无记录）的成本极低。
• 强制使用section_CS索引：如果不想创建新索引，可以用FORCE INDEX指定优化器走section_CS索引：

  SELECT * FROM `mydata`.`mytable` FORCE INDEX(section_CS)
  WHERE ((token='XFRA1NMDU9XY') AND (section=210874))
  ORDER BY mailing LIMIT 1;
  

  这样会先过滤出5000条section匹配的记录，排序后取第一条，虽然有排序步骤，但5000条数据的排序成本远低于遍历200万条记录。
• 给token字段加索引（可选）：如果token字段的查询频率较高，单独给token加索引也能提升过滤效率，但联合索引的针对性更强，对于这个特定查询的优化效果最好。

内容的提问来源于stack exchange，提问作者BurninLeo