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就是类型不一致的铁证

在MySQL中，只要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与VARCHAR(32)）、CHARACTER_SET_NAME（如utf8mb4与latin1）、COLLATION_NAME（如utf8mb4_0900_as_cs与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}拼接、Ja va里用setString()传数字ID，照样触发隐式转换

最麻烦的不是改字段，而是改完发现业务逻辑依赖前导空格、大小写敏感或混合字符——这时候COLLATE不能乱动，得配合应用层做兼容处理。