JOIN变慢的直接原因是关联字段COLLATION_NAME不一致，如utf8mb4_0900_as_cs与utf8mb4_unicode_ci混用，导致MySQL放弃索引、强制全表扫描；需通过INFORMATION_SCHEMA.COLUMNS比对并ALTER TABLE同步CHARACTER SET与COLLATE，同时确保连接层collation_connection一致。
JOIN变慢是因为关联字段Collation不一致
直接原因不是数据量大，而是MySQL在ON条件里发现两边字段的COLLATION_NAME不兼容，比如一边是utf8mb4_0900_as_cs、另一边是utf8mb4_unicode_ci，它就会放弃走索引，强制全表扫描。EXPLAIN里看到type: ALL或Extra: Using join buffer但单表很快，基本就是这个坑。
- 别只看
SHOW CREATE TABLE里写的默认值，真正起作用的是字段定义里的COLLATE，得查INFORMATION_SCHEMA.COLUMNS - 执行：
SELECT COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME IN ('t1', 't2') AND COLUMN_NAME IN ('id', 'ref_id'); - 重点比对
COLLATION_NAME列，哪怕都是utf8mb4，只要排序规则不同，就不可比
ALTER TABLE改Collation必须同时指定CHARACTER SET和COLLATE
只写MODIFY COLUMN name VARCHAR(50) CHARACTER SET utf8mb4没用——MySQL不会自动同步COLLATE，而比较时实际依赖的是排序规则。必须显式写全，且目标值要和关联表字段完全一致。
- 先确认目标字段当前的
COLLATION_NAME（用上面的查询），再选匹配项，别硬套utf8mb4_unicode_ci - 正确写法：
ALTER TABLE t2 MODIFY ref_id VARCHAR(36) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs; - 如果字段有索引，
MODIFY会重建索引；大表务必低峰期操作，否则锁表时间长 - 含外键或全文索引的表，
MODIFY可能失败，需提前删约束、改完再加回
连接层collation_connection必须和字段Collation对齐
就算表结构全统一了，如果应用连上来时@@collation_connection是utf8mb4_general_ci，而字段是utf8mb4_0900_as_cs，MySQL仍会在解析WHERE name = 'xxx'时做隐式转换，索引照样失效。
- 验证当前连接规则：
SELECT @@collation_connection; - JDBC连接串加：
?useUnicode=true&characterEncoding=utf8mb4&collationConnection=utf8mb4_0900_as_cs - PHP mysqli连接后执行：
mysqli_set_charset($conn, 'utf8mb4'); SET NAMES utf8mb4 COLLATE utf8mb4_0900_as_cs; - 临时救急可在SQL里写：
WHERE name COLLATE utf8mb4_0900_as_cs = 'xxx'，但会跳过索引，仅限验证用
主从库之间Collation不一致会悄悄让从库索引失效
主库查得快，从库EXPLAIN显示key: NULL？大概率是主从两侧字段COLLATION_NAME或@@collation_connection不一致。复制线程本身也是客户端连接，它的字符集设置会影响重放逻辑。
- 主从都要查：
SHOW FULL COLUMNS FROM tbl LIKE 'col';和SELECT @@collation_connection; - 特别注意：MySQL 5.7不支持
utf8mb4_0900_ai_ci，迁移时若从8.0导出SQL，需手动替换为utf8mb4_unicode_ci - 从库配置文件里加：
collation-server = utf8mb4_0900_as_cs，并重启生效 - 改完立刻在从库跑
EXPLAIN验证，别只信主库表现
