join会悄悄触发隐式类型转换，因关联字段字符集、排序规则或null属性不一致，导致索引失效；需通过information_schema比对三列（字符集、排序规则、是否允许null）确认一致性，修复必须统一字段定义而非仅改索引。
为什么 JOIN 会悄悄触发隐式类型转换？
MySQL 在执行 JOIN 时，如果关联字段的字符集或排序规则（collation）不一致，就会强制做隐式转换——不是你写的 CAST，而是优化器自动加的。这种转换常导致索引失效，哪怕两个字段都建了索引，EXPLAIN 里也会看到 type: ALL 或 Using join buffer。
典型诱因包括：
- 一张表用
utf8mb4_unicode_ci，另一张用utf8mb4_general_ci（collation 不同） - 一张是
utf8mb4，另一张是utf8（字符集不同） - 字段定义一个是
VARCHAR(50)，另一个是CHAR(50)（类型虽同为字符串，但对齐和比较逻辑有差异） - 其中一列是表达式或函数结果，如
UPPER(name)，而另一列是原始字段
怎么快速检查关联字段是否“真正一致”？
别只看 SHOW CREATE TABLE 里写的字符集，要查具体字段级的 collation 和是否允许 NULL。
执行这两条语句比对：
SELECT COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME, IS_NULLABLE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME IN ('table_a', 'table_b')
AND COLUMN_NAME = 'join_col';
关键看三列是否完全相同：CHARACTER_SET_NAME、COLLATION_NAME、IS_NULLABLE。哪怕只有 IS_NULLABLE 不同（比如一边是 NOT NULL，另一边允许 NULL），在某些 MySQL 版本中也可能触发转换。
修复时该改哪边？能不能只改索引？
不能只改索引——索引不存储字符集信息，它依赖字段定义。必须统一字段定义本身。
推荐操作顺序：
- 先确认业务是否允许修改字段：比如
ALTER TABLE t MODIFY col VARCHAR(100) CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci; - 如果字段上有外键，需先
DROP FOREIGN KEY，改完再重建（MySQL 8.0.19+ 支持ALTER TABLE ... ALTER COLUMN ... SET DEFAULT类语法，但改 collation 仍需重定义） - 若无法停机，可用
pt-online-schema-change在线变更，但注意它会复制整表，且新旧字段 collation 不一致时可能报错，需加--no-check-alter并人工验证 - 不要试图用
CONVERT(col USING utf8mb4)写在ON条件里“绕过”，这等于放弃索引，性能更差
MySQL 8.0 的 utf8mb4_0900_as_cs 有什么坑？
这个新 collation 是大小写敏感 + 重音敏感的二进制安全排序，看起来很“干净”，但容易被误用。
常见问题：
- 老数据里混有全角空格、零宽字符，用
_as_cs后等值比较直接失败（'a' != 'ａ'，后者是全角 a） - 应用层传来的参数默认是
utf8mb4_unicode_ci，而字段用了_as_cs，连接层没显式声明collation_connection，就会触发右侧字段转成unicode_ci再比对——又回到隐式转换 -
GROUP BY或ORDER BY涉及该字段时，排序结果和旧 collation 差异大，报表逻辑可能出错
真正要换 collation，得连应用传参、连接配置、全文检索逻辑一起动，不是改个字段就完事。
