视图JOIN字段字符集或COLLATION不一致必然触发隐式转换，导致索引失效、全表扫描（EXPLAIN显示type=ALL、key=NULL）；须用SHOW FULL COLUMNS核对并统一CHARACTER SET与COLLATION，且必须同步修改二者，仅改字符集无效。

视图JOIN字段字符集不一致会触发隐式转换

MySQL在执行JOIN时，如果两边字段的CHARACTER SET或COLLATION不同，无法直接比对，就会自动做隐式类型转换——不是报错，而是默默放弃索引，退化为全表扫描。你查视图有结果、没报错，但EXPLAIN里type: ALL、key: NULL、rows暴涨，就是这个信号。

• 常见组合陷阱：utf8mb4_general_ci vs utf8mb4_0900_as_cs，看似都是utf8mb4，但排序规则不兼容，JOIN时直接失效
• 跨库关联更危险：不同数据库可能用不同默认COLLATION，SHOW CREATE TABLE必须逐字段比对，不能只看字符集
• CONVERT(field USING utf8mb4)这类写法只是临时绕过报错，仍无法走索引，且让执行计划不稳定

修改字段字符集必须同步改COLLATION

只改CHARACTER SET不改COLLATION，等于白改。MySQL真正用来判断可比性的，是COLLATION值，不是字符集名本身。

• 正确操作示例：ALTER TABLE t2 MODIFY username VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs;
• 先查现状：SHOW FULL COLUMNS FROM t2 LIKE 'username';，确认当前Collation列值，再选匹配目标
• 大表修改会锁表+重建索引，务必在低峰期操作；若用ALGORITHM=INPLACE，需满足引擎和字段变更限制

EXPLAIN看不出视图真实执行路径

对视图直接跑EXPLAIN SELECT * FROM my_view，MySQL 8.0 只显示type: derived，完全隐藏底层JOIN是否走索引、条件有没有下推。这是排查最大盲区。

• 必须手动展开：SHOW CREATE VIEW my_view;，复制里面的SELECT语句，再对它单独EXPLAIN
• 重点盯type字段：从ref变成ALL，基本锁定字符集/类型不一致
• Extra里出现Using join buffer或Using temporary，尤其在performance_schema表上，说明已严重劣化

跨库联查报错“Illegal mix of collations”是明确提示

这个错误不是警告，是MySQL拒绝执行的硬性拦截。它说明两个字段的COLLATION在隐式转换规则下不可合并，连比较逻辑都无法确立。

• 错误信息典型格式：Illegal mix of collations (utf8mb4_0900_ai_ci,IMPLICIT) and (utf8mb4_general_ci,IMPLICIT) for operation '='
• 即使没报错，只要EXPLAIN显示key: NULL，也要怀疑是“静默失效”——字段能比对，但索引用不上
• 新表建模阶段就统一COLLATE（如全用utf8mb4_0900_as_cs），比出问题后补救成本低得多

字符集和排序规则的匹配是“毫秒级差异决定秒级延迟”的关键点，而视图本身不存数据、不建索引，所有性能责任都落在底层表定义和优化器能否识别可比性上——这点容易被忽略，但恰恰是跨库、跨迁移、跨ETL场景中最常踩的深坑。