EXPLAIN中key为NULL但possible_keys有值，说明JOIN字段索引未被使用，常见原因为字段类型不一致、字符集不同或ON子句中使用函数。
EXPLAIN里key为NULL但possible_keys有值，说明JOIN字段没走索引
这几乎可以断定关联条件“语法有效但实际失效”——字段有索引，优化器却压根没用。常见原因不是索引不存在，而是类型不一致、字符集不同或ON里用了函数。
检查步骤如下：
- 用
SHOW FULL COLUMNS FROM table_name比对两边JOIN字段的DATA_TYPE和COLLATION_NAME，尤其注意VARCHAR和INT混用、utf8mb4_general_civsutf8mb4_unicode_ci - 确认
ON子句中没出现UPPER()、DATE()、CONCAT()等任何函数调用——哪怕只在一个字段上用，该字段索引就作废 - 如果字段带前导空格或大小写不统一，别指望数据库自动归一化；先用
TRIM()和LOWER()在ETL阶段处理，而不是在ON里硬套
LEFT JOIN后结果行数远少于左表，说明右表WHERE条件误写位置
典型症状是：本该返回1万用户，结果只有200条记录，且这200条都对应右表非NULL数据。这不是数据缺失，而是WHERE把LEFT的语义破坏了。
执行顺序决定一切：先完成JOIN（含NULL行），再执行WHERE。只要右表字段参与=、IN或IS NOT NULL判断，所有NULL行立刻被剔除。
正确做法只有两个：
- 把右表过滤条件挪进
ON：比如LEFT JOIN orders ON users.id = orders.user_id AND orders.status = 'paid' - 若必须保留在WHERE，得显式接受NULL：
WHERE orders.status = 'paid' OR orders.status IS NULL，但通常语义已偏离原需求
多表JOIN中间结果暴增，大概率是关联链断裂或条件恒真
三张表连查，前两张JOIN出10万行，第三张表一加入就跳到500万行？问题不在第三张表本身，而在第二层JOIN没延续主键路径，或者写了ON 1=1这类无效条件。
例如：users JOIN orders ON users.id = orders.user_id JOIN order_items ON orders.id = order_items.order_id是安全的；但若写成JOIN order_items ON users.id = order_items.user_id，就跳过了orders表，导致每个用户直接匹配全部order_items——历史数据越多，放大越狠。
快速验证方法：
- 逐层拆开：先跑
SELECT COUNT(*) FROM users JOIN orders ON ...，再加JOIN order_items ON ...，看哪一步行数突变 - 检查每层
ON是否至少含一个明确的外键映射，避免出现ON t1.code = t2.code这种无业务含义的“碰运气”匹配 - 留意时间范围类条件是否遗漏，比如漏了
AND order_items.created_at >= '2025-01-01'，旧数据全被拉进来
ON里写OR会导致全表扫描，且无法靠优化器开关修复
这是MySQL（包括8.0）的硬限制：只要ON子句含OR，比如ON a.id = b.user_id OR a.group_id = b.group_id，优化器直接放弃所有索引，强制type: ALL。这不是配置问题，也别试optimizer_switch，它根本不支持ON条件的index_merge。
替代方案只有重构：
- 拆成两个独立JOIN再
UNION ALL：(SELECT ... FROM a JOIN b ON a.id = b.user_id) UNION ALL (SELECT ... FROM a JOIN b ON a.group_id = b.group_id) - 确保两个分支结果集互斥（比如加
WHERE a.id IS NOT NULL和WHERE a.group_id IS NOT NULL AND a.id IS NULL），避免重复 - 千万别把OR挪到
WHERE去“绕开”——那会先做笛卡尔积再过滤，中间结果可能爆炸
最易被忽略的是：类型不一致和ON里函数调用，往往在测试环境看不出问题，因为数据量小；一旦上线，索引失效+全表扫描+嵌套循环，性能断崖下跌。每次改完JOIN，务必用EXPLAIN扫一眼key和type列，别等报警才查。
