explain显示type=all或key=null说明优化器明确放弃索引，常见于被驱动表join字段缺失有效索引、类型不一致、on中使用函数、违反最左前缀或统计信息过期。
EXPLAIN 显示 type=ALL 或 key=NULL 就是没走索引
这不是“偶尔不走”，而是优化器明确放弃索引。关键看 EXPLAIN 输出里被驱动表的 type 列是否为 ALL 或 index，key 列是否为 NULL。一旦出现，说明该表在 JOIN 过程中做了全表扫描。
重点盯 rows 值：如果被驱动表的 rows 接近其总行数（比如 50 万行表显示 rows=482310），基本可断定索引完全未生效；若驱动表 rows 很小但被驱动表爆增，问题一定出在后者。
别只看表结构“看起来有关联”——必须确认索引建在 ON 子句中**实际参与比较的列**上。用 SHOW INDEX FROM table_name 检查，确保 Seq_in_index = 1 的字段与 ON 中的等值条件完全一致。
JOIN 字段类型不一致触发隐式转换
哪怕两个字段都叫 user_id，一个定义为 VARCHAR(32)，另一个是 INT，MySQL 或 PostgreSQL 就会在比较时对其中一列做隐式转换，索引直接作废。
EXPLAIN FORMAT=JSON 的 used_columns 字段可能提示类型不匹配；SQL Server 执行计划里出现 CONVERT_IMPLICIT 节点就是铁证。
检查方式：DESCRIBE table_name 或 SHOW CREATE TABLE 对比两边字段定义，包括：
- 数据类型（
INTvsVARCHAR） - 长度（
VARCHAR(20)vsVARCHAR(50)） - 符号（
SIGNEDvsUNSIGNED） - 字符集（
utf8mb4vslatin1）
临时验证可用显式转换：WHERE t1.id = CAST(t2.user_id AS SIGNED)，但生产环境必须统一字段类型，不能靠 CAST 补救。
ON 子句用了函数或表达式
ON DATE(o.create_time) = DATE(u.join_date)、ON UPPER(a.email) = UPPER(b.email)、ON a.id + 1 = b.ref_id —— 这些写法会让索引必然失效。因为索引存储的是原始值，函数调用需逐行计算，破坏 B+ 树有序性。
可行解法：
- 改存储逻辑：新增
create_date字段存日期部分，并为其建索引 - MySQL 8.0+ 可建函数索引：
CREATE INDEX idx_create_date ON orders ((DATE(create_time))) - 避免在
ON里做任何计算，哪怕只是加引号漏掉：ON a.code = 'ABC'正确，ON a.code = 123就可能触发隐式转换
复合索引没满足最左前缀原则
索引是 (user_id, status)，但 ON 条件只写了 status = ?，索引就失效。B+ 树按 user_id 排序后再按 status 排序，跳过最左列无法利用有序性。
常见误区：
- 以为“字段在索引里就行”，其实必须从最左开始连续命中
- LEFT JOIN 后带
WHERE t2.status = ?，但t2上没建status索引，问题更隐蔽 - 多表 JOIN 超 3 张时，优化器容易选错路径，即使每张表都有索引，
Using temporary和Using filesort频繁出现，说明内存已撑不住
真正难处理的不是“没建索引”，而是索引建了却因类型、函数、顺序或统计信息不准而形同虚设——这些地方一不留神就卡住整个查询链路。
