MySQL关联查询中collation不一致必然导致索引失效，因B+树依赖确定排序逻辑，collation差异使相同字符串被判定不等，优化器为保证正确性拒绝使用索引，强制全表扫描。
MySQL在关联查询中对不同排序规则的索引失效，不是“可能不走”，而是优化器直接拒绝使用索引——因为B+树依赖确定、可比的排序逻辑，collation不一致会让相同字符串在两边被判定为不等，数据库无法保证结果正确性，只能全表扫描。
JOIN时collation不一致会触发隐式CONVERT，索引列被运行时转换
只要ON条件里两个字段的COLLATION不同（比如utf8mb4_general_ci vs utf8mb4_0900_as_cs），MySQL就必须对其中一列做隐式转换，等价于写CONVERT(col USING utf8mb4) COLLATE utf8mb4_0900_as_cs。而任何对索引列的函数或转换操作，都会让该列索引失效。
- EXPLAIN中
key为NULL、type为ALL或index，就是典型信号 - Warning里可能出现
Cannot use range access on index due to type or collation conversion - 即使字符集都是
utf8mb4，只要COLLATION不同，照样失效——比较行为由collation决定，不是charset
连接层collation_connection和字段collation不匹配也会绕过索引
字段本身定义没问题，但执行SQL时的上下文规则不一致，一样会出问题。比如字段是utf8mb4_unicode_ci，而@@collation_connection是utf8mb4_0900_ai_ci，那么WHERE或ON里的字符串字面量（如'abc'）就会按后者解析，导致与字段隐式不兼容。
- 查当前连接规则：
SELECT @@collation_connection - JDBC/PDO等客户端若只设
charset=utf8mb4却没设collation，MySQL会fallback到server默认值，极易错配 - 应用层传参类型不洁（如把INT当字符串拼进SQL）也会触发同类型隐式转换，和collation无关但现象一致
ALTER TABLE改collation必须同时指定CHARACTER SET和COLLATE
只改字符集或只改排序规则都不行，MySQL实际比对的是collation，但MODIFY语句中二者必须显式并存，否则可能被覆盖成意外值。
- 正确写法：
ALTER TABLE t1 MODIFY name VARCHAR(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 错误写法：
ALTER TABLE t1 CONVERT TO CHARACTER SET utf8mb4——这只会改表默认collation，已有字段不变 - 大表操作会锁表重建索引，务必低峰期执行；MySQL 8.0+支持
ALGORITHM=INPLACE时可加该参数减少影响 - 改完立刻用
SHOW CREATE TABLE验证字段定义，再跑EXPLAIN确认key列出现索引名才算生效
别在SQL里用COLLATE或CONVERT临时绕过
有人在ON里写ON a.name = b.name COLLATE utf8mb4_unicode_ci或ON a.name = CONVERT(b.name USING utf8mb4)，看似能跑通，实则埋雷：
- 右表字段被运行时转换，
b.name上的索引完全无法使用 - 执行计划容易退化为
Using join buffer，内存压力陡增，大结果集易OOM - 这种写法把适配逻辑从DDL层推到每条SQL里，后续任何人写JOIN都得重复抄，极易遗漏或写错
- 一旦连接层collation变更，这些硬编码的COLLATE还可能突然报错
真正关键的点不在“怎么临时让SQL跑起来”，而在于字段定义、连接配置、应用传参三者collation是否严格一致——漏掉任意一层，索引就可能在某个深夜突然不走了。
