mysql关联查询失效主因是join字段collation不一致，即使字符集同为utf8mb4，如utf8mb4_unicode_ci与utf8mb4_0900_as_cs混用，优化器为保语义正确性会弃用索引导致全表扫描；须通过information_schema.columns比对collation_name，用alter table modify同时指定character set和collate统一字段定义，并确保连接层@@collation_connection一致。

MySQL 关联查询失效，往往不是索引没建，而是字段的 排序规则（COLLATION）不一致——哪怕字符集都是 utf8mb4，只要一边是 utf8mb4_unicode_ci、另一边是 utf8mb4_0900_as_cs，JOIN 就会直接弃用索引。

为什么 COLLATION 不一致会让 JOIN 失效

MySQL 在执行 JOIN 时，必须保证比较操作的语义严格一致。不同 COLLATION 对字符串的排序、大小写、重音、emoji 解析逻辑可能完全不同。比如：

• utf8mb4_unicode_ci 不区分大小写和重音（é ≈ e）
• utf8mb4_0900_as_cs 区分大小写和重音（É ≠ e）

优化器无法确认：用索引扫描出来的结果，是否和按另一套规则比较的结果完全一致。为保数据正确性，它宁可全表扫描，也不冒险走索引。

怎么一眼看出是 COLLATION 惹的祸

看 EXPLAIN 结果最直接：

• 被驱动表的 key 显示为 NULL
• type 是 ALL 或 index（而不是 ref/eq_ref）
• 单表查询很快，一 JOIN 就几秒甚至几分钟

这时别急着加索引，先查字段真实 COLLATION：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

SELECT column_name, character_set_name, collation_name FROM INFORMATION_SCHEMA.COLUMNS WHERE table_name IN ('t1', 't2') AND column_name = 'user_id';

改字段 COLLATION 的正确姿势

不能只改字符集，也不能只在 SQL 里加 COLLATE 临时转换——这些都不影响索引使用。必须修改字段定义本身，且CHARACTER SET 和 COLLATION 要同时指定：

ALTER TABLE t2 MODIFY user_id VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

• 先用 SHOW FULL COLUMNS FROM t2 LIKE 'user_id' 确认当前值
• 目标 COLLATION 必须和关联字段一字不差
• 有索引会重建，大表务必低峰期操作

连接层不统一，改完也白搭

字段对齐了，但应用连进来时 @@collation_connection 是 utf8mb4_general_ci，那 SQL 里的 'abc' 字面量仍会被按错误规则解释，触发隐式转换，索引照样失效。

验证方式：

SELECT @@collation_connection;

修复方式（以 JDBC 为例）：

jdbc:mysql://host/db?useUnicode=true&characterEncoding=utf8mb4&collationConnection=utf8mb4_unicode_ci