EXPLAIN显示key为NULL是因JOIN或WHERE中字段collation_name不一致导致MySQL主动弃用索引；须用SHOW FULL COLUMNS和SELECT @@collation_connection比对字段、连接及字面量三层collation，统一为完全相同的utf8mb4_0900_as_cs等规则，并通过ALTER TABLE MODIFY同时指定CHARACTER SET与COLLATE验证生效。
EXPLAIN 显示 key 为 NULL 但字段明明有索引，先查 COLLATION 是否对齐
这不是索引没建好，而是 MySQL 在 JOIN 或 WHERE 比较前发现两边字段的 collation_name 不一致，主动弃用索引。别猜哪边错了，直接查：
- 查左表关联字段：
SHOW FULL COLUMNS FROM table1 LIKE 'join_col';，看Collation列 - 查右表关联字段：
SHOW FULL COLUMNS FROM table2 LIKE 'join_col'; - 查当前连接默认规则：
SELECT @@collation_connection; - 查 SQL 字面量隐含的 collation（比如
'abc'）：它由@@collation_connection决定
只要任意一对不完全相同（例如 utf8mb4_unicode_ci vs utf8mb4_0900_as_cs），就可能触发隐式转换，导致 key 为 NULL、type 变成 ALL。
ALTER TABLE 修改字段时必须同时指定 CHARACTER SET 和 COLLATE
只写 ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 是无效操作——它不会改已有字段的 COLLATE，大概率保留旧值，比如 utf8mb4_general_ci，而你真正需要的是 utf8mb4_0900_as_cs。
- 正确写法：
ALTER TABLE table2 MODIFY join_col VARCHAR(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs; - 错误写法：
ALTER TABLE table2 CONVERT TO CHARACTER SET utf8mb4;或ALTER TABLE table2 MODIFY join_col VARCHAR(64) COLLATE utf8mb4_0900_as_cs;（漏了CHARACTER SET） - 修改后立刻验证：
SHOW CREATE TABLE table2;确认字段定义里同时出现CHARACTER SET utf8mb4和COLLATE utf8mb4_0900_as_cs
大表操作会锁表重建索引，MySQL 8.0+ 若满足条件可加 ALGORITHM=INPLACE，但需提前测试。
JOIN 场景下两边字段 COLLATION 必须完全一致，不能只靠连接层补救
即使应用层设置了 collationConnection=utf8mb4_0900_as_cs，如果两张表的关联字段一个用 utf8mb4_unicode_ci、另一个用 utf8mb4_0900_as_cs，MySQL 仍无法安全使用索引做等值比较——B+ 树依赖严格有序，不同 collation 下 'a' = 'A' 的判定结果可能不同，优化器宁可全表扫描也不冒错。
- 用
INFORMATION_SCHEMA.COLUMNS批量比对：SELECT table_name, column_name, character_set_name, collation_name FROM INFORMATION_SCHEMA.COLUMNS WHERE table_name IN ('t1', 't2') AND column_name = 'join_col'; - 外键字段也适用此规则，哪怕没显式 JOIN，约束检查时同样触发 collation 比对
- 临时在 ON 条件里加
COLLATE或CONVERT（如ON t1.col = t2.col COLLATE utf8mb4_0900_as_cs）会让索引彻底失效，且后续所有 SQL 都得重复写，不可维护
应用连接串必须显式声明 collationConnection，否则改表白干
表和字段都改好了，但 JDBC、PDO 或命令行客户端连上来时没带 collation 参数，@@collation_connection 仍是服务端默认值（比如 latin1_swedish_ci），那 SQL 中的字符串字面量（如 WHERE name = '张三'）就会按错误规则解析，和字段 collation 不匹配，照样触发隐式转换。
- JDBC 连接串加：
?useUnicode=true&characterEncoding=utf8mb4&collationConnection=utf8mb4_0900_as_cs - PHP mysqli 连接后执行：
mysqli_set_charset($conn, 'utf8mb4');+mysqli_query($conn, "SET NAMES utf8mb4 COLLATE utf8mb4_0900_as_cs"); - 验证是否生效：
SELECT CHARSET('x'), COLLATION('x');返回值应与字段一致
最容易被忽略的是：字符集（CHARACTER SET）相同但排序规则（COLLATE）不同，就足以让索引失效——这不是配置疏漏，是 MySQL 优化器的硬性限制，必须三层（字段、连接、字面量）全部对齐才算真正解决。
