应直接修改字段定义而非SQL中硬加COLLATE或CONVERT，否则索引失效；通过EXPLAIN中type=ALL、key为空或报错“Illegal mix of collations”识别COLLATION冲突；需用INFORMATION_SCHEMA查具体字段排序规则，注意SHOW CREATE TABLE末尾默认值不反映字段实际声明；常见冲突组合如utf8mb4_general_ci与utf8mb4_0900_as_cs；ALTER TABLE MODIFY必须同时指定CHARACTER SET和COLLATE，且目标COLLATE须与关联字段完全一致；改后须用SHOW CREATE TABLE确认；大表操作需低峰期执行；外键、UNION、GROUP BY、GROUP_CONCAT等均受COLLATION影响，相关字段定义必须统一。
直接改字段定义，别在SQL里硬加COLLATE或CONVERT——那些写法看着能过语法，但索引照样失效，查询照慢不误。
怎么一眼看出是COLLATION冲突？
看到EXPLAIN里被驱动表的type是ALL、key为空，或者报错信息里有Illegal mix of collations，基本就是它了。
- 查具体字段的排序规则：用
SELECT COLUMN_NAME, COLLATION_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 't1' AND COLUMN_NAME = 'user_id' - 别只看
SHOW CREATE TABLE末尾的默认值，得盯住字段那一行的CHARACTER SET和COLLATE实际声明 - 常见坑组合：
utf8mb4_general_civsutf8mb4_0900_as_cs、utf8mb4_unicode_civsutf8mb4_0900_ai_ci——同属utf8mb4字符集，但规则互不兼容
ALTER TABLE MODIFY必须同时指定CHARACTER SET和COLLATE
只改字符集不改排序规则，等于没改；只改排序规则不声明字符集，MySQL可能按旧字符集推导出不匹配的默认COLLATE。
- 正确写法：
ALTER TABLE t2 MODIFY user_id VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs - 目标
COLLATE必须跟关联表字段完全一致，不能“差不多就行” - 改完立刻执行
SHOW CREATE TABLE t2确认字段定义已更新，别只信SHOW FULL COLUMNS返回的Collation列 - 大表操作会锁表、重建索引，务必低峰期执行；含外键或全文索引的字段，
MODIFY可能失败，需提前处理约束
JOIN字段以外的地方也得同步检查
只修ON条件里的字段，其他地方照样崩。外键、UNION、GROUP BY、GROUP_CONCAT都受COLLATION影响。
- 外键字段
COLLATION不一致，建表或插入时就可能报ERROR 1005: Can't create table -
UNION结果集要求所有列字符集+排序规则完全一致，否则直接报错 -
GROUP BY dept_name分组漂移，往往是因为两张表的dept_name字段COLLATE不同，导致“张三”和“張三”被当成不同值 -
GROUP_CONCAT乱码不是拼接问题，是连接层collation_connection跟字段COLLATE不匹配，得一起对齐
真正容易被忽略的是：这些字段往往不在日常JOIN语句里显式出现，比如外键列、GROUP BY字段、UNION子查询的输出列——它们默默参与比较，却没人检查定义是否统一。
