EXPLAIN中type=ALL、key=NULL是JOIN字段类型/字符集/COLLATION不一致的铁证，需通过INFORMATION_SCHEMA.COLUMNS比对DATA_TYPE、CHARACTER_SET_NAME、COLLATION_NAME和IS_NULLABLE四列是否完全一致，统一修改必须同时指定CHARACTER SET和COLLATE。
EXPLAIN里type=ALL、key=NULL就是类型不一致的铁证
只要JOIN条件两边字段类型、字符集或校对规则（COLLATION）任一不同，MySQL就会强制隐式转换，索引必然失效。最直接的表现是EXPLAIN中对应表的type为ALL、key为NULL，或者Extra出现Using where; Using join buffer。这不是“可能慢”，而是B+树索引结构被破坏后的必然结果——优化器根本无法下推等值查找。
怎么查字段级定义，而不是只看SHOW CREATE TABLE
SHOW CREATE TABLE只显示表级默认值，掩盖字段真实定义。必须查INFORMATION_SCHEMA.COLUMNS：
SELECT COLUMN_NAME, DATA_TYPE, CHARACTER_SET_NAME, COLLATION_NAME, IS_NULLABLE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'your_db'
AND TABLE_NAME IN ('t1', 't2')
AND COLUMN_NAME = 'join_col';
重点比对四列是否完全一致：DATA_TYPE（如BIGINT vs VARCHAR(32)）、CHARACTER_SET_NAME（如utf8mb4 vs latin1）、COLLATION_NAME（如utf8mb4_0900_as_cs vs utf8mb4_unicode_ci）、IS_NULLABLE（一边NOT NULL，一边允许NULL在MySQL 8.0某些版本也会触发转换）。
为什么CAST/CONVERT/加0都是坑
这些写法看似让SQL跑通，实则把性能开销甩给每次查询：
-
ON u.id = CAST(o.user_id AS BIGINT)：函数作用于索引列，B+树失效，EXPLAIN里仍是type: ALL -
ON u.id = o.user_id + 0（MySQL）：遇到'123abc'或' 123 '会静默转成0或截断，结果错误 -
ON a.name = b.name COLLATE utf8mb4_unicode_ci：只是CPU换可运行，索引依然用不上 - PostgreSQL的
::integer或SQL Server的CONVERT(INT, ...)同样不能走索引，且原字段含空格或非数字时直接报错中断
ALTER TABLE统一字段类型的实际雷区
这是唯一根治方式，但操作前必须踩准几个点：
- 先扫脏数据：
SELECT COUNT(*) FROM t WHERE id REGEXP '[^0-9]'（MySQL）或SELECT COUNT(*) FROM t WHERE id !~ '^[0-9]+$'（PostgreSQL），确保字符串真能全转成数字 - 外键字段要先
DROP FOREIGN KEY，改完再ADD CONSTRAINT；主键字段修改需锁表，评估业务窗口 - 字符集和COLLATION必须一起改：
MODIFY COLUMN user_id BIGINT NOT NULL CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs，只改类型不改字符集，照样失效 - 跨库JOIN时，两个库的默认字符集可能不同，得分别检查并统一
- 应用层代码常被忽略：数据库字段对齐了，但MyBatis里还是用
${id}拼接、Java里用setString()传数字ID，照样触发隐式转换
