join不走索引主因是连接字段类型、字符集或排序规则不一致，导致隐式转换使索引失效；表现为explain中key为null、type=all；须用show create table和show full columns核对data_type、charset、collate、null属性，并统一修正。
JOIN不走索引，八成不是SQL写得不好，而是底层字段“看着像、其实不一样”——类型、字符集、排序规则三者只要有一个对不上，EXPLAIN里key就变NULL，type就掉到ALL。
查字段类型是否一致（INT vs VARCHAR最常见）
MySQL在ON条件里做等值比较时，如果一边是INT、另一边是VARCHAR，会把整数转成字符串去比，结果就是整数列的索引彻底失效。这不是bug，是隐式转换的必然代价。
- 现象：
EXPLAIN显示type=ALL或key=NULL，哪怕两边字段都建了主键/索引 - 验证：跑
SHOW CREATE TABLE table_a和SHOW CREATE TABLE table_b，逐字比对JOIN字段的DATA_TYPE、CHARACTER SET、COLLATE、NULL属性 - 典型错误：
users.id INT与orders.user_id VARCHAR(20)直接写ON u.id = o.user_id - 临时绕过（不推荐）：
ON u.id = CAST(o.user_id AS SIGNED)，但o.user_id索引依然无效 - 根治：统一类型，比如
ALTER TABLE orders MODIFY user_id INT NOT NULL
查字符集和COLLATION是否完全相同
两个VARCHAR字段，哪怕都是utf8mb4，只要COLLATE不同（比如utf8mb4_general_ci vs utf8mb4_0900_as_cs），MySQL照样拒绝用索引——它连“相等”的语义都无法安全推断。
- 现象：
possible_keys有值，key却是NULL；SHOW WARNINGS可能提示Cannot use range access on index due to type or collation conversion - 验证命令：
SHOW FULL COLUMNS FROM table_a LIKE 'field_name'，重点看Collation列 - 别只改
CHARACTER SET：ALTER TABLE t MODIFY col VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs必须同时指定两者 - 硬加
COLLATE到SQL里（如ON a.name = b.name COLLATE utf8mb4_0900_as_cs）通常无效，优化器仍会放弃索引
查ON条件里有没有函数或表达式
只要在ON子句里对索引字段做了任何计算，比如UPPER()、DATE()、CONCAT()，那个字段的索引就当场作废。这不是MySQL特有，PostgreSQL、Oracle同样如此。
- 反例：
ON u.email = LOWER(o.contact_email)→u.email索引失效；ON DATE(o.created_at) = '2024-01-01'→created_at索引失效 - 替代方案：数据入库时就标准化（邮箱存小写、时间存日期+时间分开字段），避免运行时转换
- 时间范围务必用闭区间：
o.created_at >= '2024-01-01' AND o.created_at ，而不是<code>DATE()函数 - 真绕不开函数？考虑生成列：
ALTER TABLE orders ADD COLUMN contact_email_lower VARCHAR(255) GENERATED ALWAYS AS (LOWER(contact_email)) STORED，再给它建索引
确认被驱动表的索引真的可用
LEFT JOIN中左表是驱动表，右表是被驱动表；INNER JOIN中优化器选小表当驱动表。但无论哪种，**被驱动表的JOIN字段必须有独立索引**——复合索引只有当前缀完全匹配时才生效。
- 错误假设：
orders表有INDEX(user_id, status)，就以为ON u.id = o.user_id能用上 - 实际要求：
user_id必须是该复合索引的最左前缀，且查询没用到status条件时，仍可命中；但如果user_id只是第二列（比如INDEX(status, user_id)），就完全无效 - 验证方法：
EXPLAIN FORMAT=TREE看执行计划里是否出现ref或eq_ref，而非ALL或index - 别依赖
FORCE INDEX：它可能压住问题但掩盖病因，优先修复表结构和SQL逻辑
真正容易被忽略的，是那些“看起来没问题”的字段——比如从CSV导入时自动生成的VARCHAR主键、ETL脚本里没显式声明COLLATE的字段、或者历史表沿用utf8而新表默认utf8mb4_0900_as_cs。这些差异不会报错，只会悄悄让查询慢十倍。排查时别只盯着SQL，先翻SHOW CREATE TABLE。
