在Navicat中执行EXPLAIN SELECT，重点看key和type：key非NULL且type为ref/range表示索引生效；key为NULL或type=ALL说明未走索引或全表扫描。
Navicat里怎么看EXPLAIN结果里的key和type
直接在navicat查询窗口执行 explain select ...，重点盯住两列：key 和 type。如果 key 显示的是你刚建的联合索引名（比如 idx_user_status），且 type 是 ref 或 range，说明索引大概率被用了；如果 key 为 null 或显示别的索引名，那这个联合索引根本没进优化器的法眼。
常见误判点：
-
possible_keys有你的索引名 ≠ 实际用了它——这只是备选名单，key才是最终上岗的 -
type=ALL表示全表扫描，基本等于索引失效，得立刻查WHERE条件是否跳过了最左列 -
key_len值偏小（比如建了(a,b,c)索引，但key_len只对应a的长度），说明只用上了第一列
为什么WHERE条件顺序和索引字段顺序必须严格一致
MySQL不会重排你的索引字段顺序，也不会智能匹配“条件写了但顺序不对”的情况。建了 (user_id, status)，但写成 WHERE status = 'active' AND user_id = 123，照样不走索引——优化器只认最左前缀连续匹配。
实操建议：
- 把高频查询的WHERE字段顺序，原样复制到Navicat索引字段添加顺序里（拖动调整位置很关键）
- 如果业务中真有
WHERE status = ? AND user_id = ?这种固定写法，索引就得建为(status, user_id)，而不是反过来 - 别依赖ORM自动生成的SQL顺序，用Navicat的查询窗口手动粘贴原始SQL再EXPLAIN
Navicat界面建的联合索引，MySQL版本不支持DESC怎么办
Navicat在索引页允许你为每列设 ASC 或 DESC，但这只是界面功能。MySQL 5.7及更早版本根本不支持多列混合排序方向，你设了 DESC 也白搭，实际存储全是 ASC。
验证方法：
- 建完索引后，右键表 → “查看表详情” → 切到“DDL”标签页，看生成的
CREATE INDEX语句里有没有真实出现DESC - 如果语句里是
ASC（或干脆没写，默认就是ASC），而你用的是MySQL 5.7，那界面上选的DESC就是摆设 - ORDER BY 场景下想用
a ASC, b DESC，必须确认 MySQL 版本 ≥ 8.0，否则得改写SQL或接受 filesort
联合索引建了但EXPLAIN显示没用，先查这三件事
不是索引建错了，就是查询踩了隐性坑。别急着删重建，先快速过一遍：
- 查
SHOW INDEX FROM table_name，确认索引名、字段顺序、类型（INDEX还是UNIQUE）和Seq_in_index序号是否符合预期 - 查该字段是否有
NULL值，尤其是最左列——WHERE a IS NULL不走B+树查找，type会退化成index或更差 - 查SQL里有没有
OR、LIKE '%xxx'、函数包裹字段（如WHERE YEAR(created_at) = 2024），这些都会让联合索引前功尽弃
Navicat不会告诉你这些陷阱，它只负责把DDL写进去。生效与否，全靠你对着EXPLAIN一行行比对。
