mysql跨字符集关联查询不走索引，因collation不一致触发隐式转换，导致type: all、key: null及block nested loop join；需用show full columns比对collation并显式alter table统一为utf8mb4_0900_ai_ci。
MySQL在跨字符集关联查询时，根本不会走索引——哪怕两个字段都有索引，只要字符集或排序规则（collation）不一致，优化器就会放弃使用索引，退化为全表扫描。这不是配置问题，而是类型隐式转换导致的硬性限制。
为什么product_id字段字符集不一致会导致type: ALL？
当table_a.product_id是 utf8/utf8_bin，而table_b.product_id是 utf8mb4/utf8mb4_0900_ai_ci时，MySQL无法直接比较两个值：它必须对其中一列做隐式转换（比如把utf8转成utf8mb4），而这个过程会让索引失效。
- 执行计划里看到
type: ALL和key: NULL就是典型信号 -
EXPLAIN的Extra字段若出现Using where; Using join buffer，说明已退化为 Block Nested Loop Join，性能急剧下降 - 即使数据量仅几万行，这种隐式转换也可能让查询从毫秒级拖到分钟级
如何快速定位字符集/排序规则不一致？
别猜，直接查字段定义。跨库查询尤其容易忽略这点，因为两个库可能由不同团队维护，建表脚本不统一。
- 用
SHOW FULL COLUMNS FROM db1.table1 LIKE 'product_id'查左边字段 - 用
SHOW FULL COLUMNS FROM db2.table2 LIKE 'product_id'查右边字段 - 重点比对
Collation列，不是只看Charset—— 比如utf8mb4_unicode_ci和utf8mb4_0900_ai_ci也不兼容
修复时必须统一 collation，不能只改 charset
只执行 ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 是不够的，它默认用 utf8mb4_800_ci_ai（MySQL 8.0+ 默认），但老表可能是 utf8mb4_general_ci 或其他。必须显式指定 collation。
- 推荐统一为
utf8mb4_0900_ai_ci（MySQL 8.0+ 推荐，默认支持 Unicode 9.0） - 执行：
ALTER TABLE db1.table1 MODIFY COLUMN product_id VARCHAR(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci - 注意：修改前确认该字段无业务逻辑依赖特定排序行为（比如大小写敏感匹配）
- 如果字段是主键或外键，需先删约束、改字段、再重建约束
跨库关联时最容易被忽略的细节
开发者常以为“只要在同一个实例里，跨库和同库没区别”，但字符集校验发生在解析阶段，跟库名无关。哪怕两个表物理上在同一磁盘、同一 InnoDB 表空间，只要 collation 不一致，就触发隐式转换。
更隐蔽的是：某些 ORM 自动生成的 SQL 会带 COLLATE 子句，或客户端连接参数（collation_connection）影响临时表达式排序规则，导致偶发失效。所以线上环境务必用 SHOW VARIABLES LIKE 'collation%' 核对会话级设置。
