关联字段字符集或排序规则不一致必然导致join索引失效，因mysql优化器需严格有序比较，collation差异使相同字符串判定不等，无法保证结果正确性，被迫全表扫描；须用show full columns比对collation、character set、type三者是否完全一致，并统一修改字段定义。
关联字段字符集或排序规则不一致导致索引失效
MySQL在执行 JOIN 时，如果关联字段的字符集（CHARACTER SET）或排序规则（COLLATION）不一致，优化器会拒绝使用索引——哪怕两边都有索引、类型也都是 VARCHAR。这不是“没建索引”，而是“建了也用不上”。
常见现象是：EXPLAIN 显示 type 为 ALL 或 index，key 为 NULL，但单表查询明明能走索引。
- 比如
orders.user_id是utf8mb4_unicode_ci，而users.id是utf8mb4_general_ci，即使都是VARCHAR(32)，JOIN 也会强制隐式转换，触发全表扫描 - 更隐蔽的是跨库 JOIN：主库用
utf8mb4，从库同步后被改成了utf8，字段看起来一样，实际比较时无法对齐 -
SHOW CREATE TABLE查出的COLLATION可能和实际字段不一致——某些 ORM 或迁移工具会漏掉显式声明，依赖默认值，而不同 MySQL 版本默认值不同
如何快速确认字符集/排序规则是否匹配
别猜，直接查。对两个关联字段分别执行：
SHOW FULL COLUMNS FROM orders LIKE 'user_id';
SHOW FULL COLUMNS FROM users LIKE 'id';
重点比对三列：Collation、Character Set、Type。只要其中任意一项不一致，就可能让索引失效。
注意：utf8mb4_0900_as_cs 和 utf8mb4_unicode_ci 虽然都属 utf8mb4，但排序规则不同，仍会导致不匹配；utf8 和 utf8mb4 更是完全不兼容。
修复时不要只改表结构
ALTER TABLE 修改字符集看似简单，但容易踩坑：
- 仅改字段定义（
MODIFY COLUMN）不等于重写数据，旧数据可能残留乱码，且不会自动重建索引 - 用
CONVERT TO CHARACTER SET会重写整张表，大表阻塞严重，且可能触发复制延迟 - 最稳妥的做法是：先在测试环境导出字段定义 + 索引定义 → 手动统一
COLLATION→ 重建索引 → 验证EXPLAIN
如果业务已上线且不能停写，可临时加 COLLATE 强制对齐（仅限小流量验证）：
SELECT * FROM orders o JOIN users u ON o.user_id = u.id COLLATE utf8mb4_unicode_ci;
但这只是绕过问题，不是解决——长期依赖 COLLATE 会让执行计划不稳定，且无法利用索引下推（ICP）。
联合索引中关联字段位置影响更大
如果关联字段是复合索引的一部分（比如 INDEX idx_user_status_time(user_id, status, create_time)），字符集不一致的影响会被放大：
- 即使
user_id单独有索引，复合索引中的user_id段也无法用于 JOIN 条件匹配 - 优化器可能放弃整个复合索引，转而用其他单列索引，甚至全表扫描
- 此时
key_len在EXPLAIN中会明显变短（比如预期 130，实际只有 5），就是信号
真正难排查的，往往不是“有没有索引”，而是“为什么这个索引明明存在，却像没建一样”。字符集和排序规则这种底层元信息，一旦错位，连优化器自己都懒得解释清楚——它只会默默退回到全表扫描。
