查询慢不一定因缺少索引，可能源于函数/表达式导致索引失效、隐式类型转换、统计信息过期、低选择性索引、覆盖不全、索引过宽、ORDER BY/GROUP BY未优化、临时表落盘等细节问题。
不一定。查询慢的根源可能在索引之外，盲目加索引甚至会让性能更差。
执行计划里 type 是 ALL 就一定没走索引？
不一定。ALL 表示全表扫描，但原因可能是：
- WHERE 条件用了函数或表达式，比如
WHERE YEAR(create_time) = 2024，导致索引失效 - 字段存在隐式类型转换，比如
user_id是VARCHAR，但查询写成WHERE user_id = 123（数字），MySQL 会转成字符串再比，但索引 B+ 树按原始类型排序，无法跳查 - 统计信息过期，优化器误判了数据分布，选了错误的执行路径——这时
ANALYZE TABLE可能比加索引更有效
EXPLAIN 显示走了索引，但还是慢？
说明索引被用了，但未必高效。常见情况有：
- 索引选择性低：比如在
gender字段建索引，只有 'M'/'F' 两个值，回表代价高，优化器可能干脆放弃走索引 - 覆盖索引没做全：SELECT 的字段没全包含在索引里，要反复回表查聚簇索引，IO 拉满；加
INCLUDE（SQL Server）或建联合索引把常用查询字段“拖进来”更直接 - 索引太宽：联合索引字段太多、或者含大字段（如
TEXT），导致单页存的索引项少，树高增加，B+ 树遍历变慢
没查 WHERE，只查 ORDER BY 或 GROUP BY 也慢？
这类场景容易被忽略，但恰恰是索引设计盲区：
-
ORDER BY a, b慢？建(a, b)索引可避免文件排序（Using filesort）；但如果语句里还有LIMIT 100000, 20，即使有索引，也要先扫 100020 行——这时分页该用游标（WHERE id > ? ORDER BY id LIMIT 20） -
GROUP BY慢？注意 MySQL 8.0+ 默认用松散索引扫描（Loose Index Scan），但前提是索引顺序和 GROUP BY 字段顺序严格一致，且无聚合函数外的非索引字段参与 SELECT - 临时表撑爆内存：
GROUP BY或DISTINCT数据量大时，tmp_table_size和max_heap_table_size设得太小，会强制落磁盘，速度断崖下跌
真正卡住查询的，常是那些不报错、不告警、EXPLAIN 看着“一切正常”的细节：字符集不一致引发的隐式转换、统计信息陈旧、排序缓冲区不够、甚至只是客户端一次拉了 50 万行 JSON 字符串回来自己解析。调优得从执行计划往下挖三层，而不是盯着“有没有索引”打转。
