SQL 查询慢一定是索引问题吗？

查询慢不一定因缺少索引，可能源于函数/表达式导致索引失效、隐式类型转换、统计信息过期、低选择性索引、覆盖不全、索引过宽、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 字符串回来自己解析。调优得从执行计划往下挖三层，而不是盯着“有没有索引”打转。