mysql对limit查询走全表扫描，是因为优化器基于成本模型判断索引路径总开销（预估扫描行数×回表开销）高于全表扫描，即使只取1行；常见原因包括高匹配行数、低区分度索引、select*导致大量回表、统计信息过期及order by不匹配索引顺序。
MySQL 对 LIMIT 查询走全表扫描，不是索引没建好，也不是配置错了，而是优化器算完账后觉得“扫全表更省”——哪怕你只想要 1 行，它也可能放弃索引。
为什么 LIMIT 1 还会 type=ALL？
优化器不看你要几行，只看「走索引要花多少钱」。如果满足条件的行太多、回表代价太高、或索引区分度太低，它就会选全表扫描。
-
WHERE条件匹配行数占比高（比如status != 'done'覆盖 95% 的数据），索引定位后还得回表取大量字段，I/O 成倍增加 - 查询用了
SELECT *，而索引不覆盖所有字段，每次命中都要回聚簇索引查一遍，开销远超顺序读 - 索引列基数极低（如
gender只有 'M'/'F'），Cardinality接近总行数的 1/2，优化器预估过滤效果差 - 连接字符集与字段字符集不一致（比如字段是
utf8mb4，但客户端连的是latin1），触发隐式CONVERT()，等价于对索引列用了函数
EXPLAIN 显示用了索引，但 rows 还是百万级
这说明索引“被用了”，但没起效——本质是优化器误判了选择率，或者统计信息严重过期。
- 先查真实基数：
SHOW INDEX FROM t WHERE Key_name = 'idx_xxx';，对比Cardinality和实际行数；若偏差大（比如总行 100 万，Cardinality只有 2000），说明采样不准 - 强制刷新：
ANALYZE TABLE t;（注意锁表，避开高峰） - 长期高频写入的表，建议开启持久化统计：
SET GLOBAL innodb_stats_persistent = ON;+innodb_stats_auto_recalc = ON; - 别只盯
key是否非空，重点看rows是否接近你预期的命中的行数；如果rows=982341而你只想要 1 行，那这个“索引扫描”和全表扫没区别
联合索引 + LIMIT 时排序失效导致退化
即使 WHERE 走了索引，ORDER BY 不匹配索引顺序，也会触发 Using filesort，甚至让整个执行路径降级为 type=index 或 ALL。
- 例如索引是
idx_a_b_c (a,b,c)，但查询是WHERE a = 1 ORDER BY b DESC, c ASC—— 如果 MySQL 8.0 之前没建DESC索引，它只能反向遍历，成本飙升 - 解决办法：显式建降序索引，如
CREATE INDEX idx_a_b_desc_c_asc ON t (a, b DESC, c ASC); - 更狠一招：把
ORDER BY字段加进WHERE条件下推到子查询里，比如用延迟关联：SELECT * FROM t JOIN (SELECT id FROM t WHERE a = 1 ORDER BY b,c LIMIT 10) tmp ON t.id = tmp.id; - 务必确保
JOIN条件用的是主键或唯一索引字段，否则驱动表放大扫描量
真正容易被忽略的点
你建了索引、写了 WHERE、加了 LIMIT，但没跑 EXPLAIN FORMAT=JSON 看成本明细，也没比对 rows 和真实匹配数——那就等于没诊断。优化器不会告诉你它怎么想的，除非你主动打开 optimizer_trace；而 key_len 偏小、filtered 接近 1.00、Extra 里反复出现 Using where，这些才是索引“形同虚设”的真实信号。
