type=ALL表示MySQL对整张表逐行扫描，不走任何索引，是最慢的访问类型；key为空但possible_keys有值说明优化器弃用了可用索引，常见于函数操作、索引顺序不匹配、隐式类型转换或统计信息过期。
EXPLAIN里type=ALL说明什么
type=all表示mysql正在对整张表逐行扫描，不走任何索引。这是最慢的访问类型，尤其在百万级以上数据量时，响应可能从毫秒级升至数秒。它不是“偶尔慢”，而是每次执行都稳定地慢——只要where、join或order by条件没命中有效索引，就会触发。
key为空但possible_keys有值怎么办
这说明表上有可用索引（possible_keys非空），但优化器主动弃用了它。常见原因包括：
• WHERE条件中对索引字段用了函数，比如YEAR(create_time)=2023；
• 索引列顺序与查询条件不匹配，例如复合索引是(status, user_id)，但查询只写了WHERE user_id = 123；
• 字段存在隐式类型转换，比如user_id是VARCHAR但传入了数字123；
• 统计信息过期，执行ANALYZE TABLE your_table;可强制刷新。
怎么建索引才真正被EXPLAIN用上
别一上来就给每个WHERE字段单独建索引。优先按以下顺序判断：
• 先看WHERE等值条件：把高频、高区分度的字段放复合索引最左；
• 再叠加ORDER BY字段：如果查询含ORDER BY create_time DESC，且该字段常和WHERE status='active'一起出现，索引应为(status, create_time)；
• 覆盖查询需求：若SELECT id, name, status，而索引是(status, name, id)，就能避免回表，Extra里不会出现Using filesort或Using where；
• 避免冗余索引：已有(a, b)，再建(a)意义不大，删除后者。
哪些写法会让索引彻底失效
即使索引建得再准，SQL写法不对也白搭：
• WHERE column IS NULL或WHERE column != 'x'：几乎无法使用B+树索引；
• WHERE column LIKE '%abc'：前导通配符导致索引失效；
• WHERE col1 + col2 > 100：表达式计算使索引列脱离原始形态；
• WHERE JSON_EXTRACT(data, '$.name') = 'Alice'：除非建了生成列并对其索引，否则JSON字段上的函数调用不走索引。
EXPLAIN里的key列真正填上值，且rows接近实际返回行数——差一个数量级，就说明索引没对上路子。 
