JOIN 变慢常因字段字符集或排序规则不一致导致隐式转换，使索引失效、触发全表扫描；需用 SHOW CREATE TABLE 和 EXPLAIN 核查 Collation 与执行计划，并通过 ALTER TABLE 统一字符集和排序规则。
为什么 JOIN 突然变慢？先查字段字符集是否对齐
Navicat 本身不直接暴露字符集隐式转换细节，但只要 JOIN 条件两边字段的字符集或排序规则（collation）不一致，MySQL 就无法使用索引，强制全表扫描。最常见的是 utf8mb4_general_ci 和 utf8mb4_unicode_ci 混用，或一边是 utf8mb4、另一边是 utf8（已弃用但存量多）。
实操建议：
- 在 Navicat 中右键点击参与
JOIN的两张表 →「对象信息」→ 切换到「列」页签，逐列核对Collation值是否完全一致 - 重点检查
ON条件中涉及的字段，比如users.name和orders.user_name，哪怕类型都是VARCHAR(50)，Collation不同也会触发隐式转换 - 用 Navicat 执行
SHOW CREATE TABLE `table_name`，直接看建表语句里每个字段的COLLATE定义，比图形界面更可靠
用 EXPLAIN 看懂“为什么没走索引”
字符集不匹配时，EXPLAIN 的 type 字段会显示 ALL（全表扫描），且 key 为 NULL，即使该字段明明建了索引。关键要看 Extra 列是否出现 Using where; Using join buffer (Block Nested Loop) —— 这是隐式转换的典型信号。
实操建议：
- 在 Navicat 查询窗口执行
EXPLAIN SELECT ... FROM t1 JOIN t2 ON t1.col = t2.col，不要省略EXPLAIN - 如果
t2.col的Collation和t1.col不同，MySQL 会把t2.col转成t1.col的字符集再比对，导致无法命中t2.col上的索引 - 临时验证：给
t2.col加COLLATE强制对齐，例如ON t1.col = t2.col COLLATE utf8mb4_unicode_ci，再跑EXPLAIN—— 若type变成ref且key显示索引名，就坐实了字符集问题
修改字符集要连带改排序规则，只改 CHARACTER SET 不够
用 Navicat 修改表结构时，右键字段 →「修改字段」→ 改 Character set 下拉框，很容易忽略下面的 Collation 下拉框。MySQL 要求字符集和排序规则必须兼容，比如设成 utf8mb4 却保留 utf8_general_ci，会报错或静默降级。
实操建议：
- 批量修正推荐用 SQL：在 Navicat 中执行
ALTER TABLE t2 MODIFY COLUMN col VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 注意
MODIFY COLUMN会重建字段，若表大需评估锁表现；CHANGE COLUMN功能相同，但语法稍冗余 - 改完立刻执行
SHOW FULL COLUMNS FROM t2 LIKE 'col'，确认Collation列已更新，别只信 Navicat 界面刷新
Navicat 连接设置里的 charset 不影响表字段字符集
很多人在 Navicat「连接属性」→「高级」里把 Initial charset 设成 utf8mb4，以为能“解决”关联问题 —— 这只是控制客户端与服务端通信编码，和表/字段定义的字符集无关。它影响的是你输入的 SQL 文本和返回结果的编码，不是 JOIN 的执行逻辑。
实操建议：
- 这个设置只在你写中文条件（如
WHERE name = '张三'）或导出含中文数据时起作用，对索引选择无任何影响 - 真正要改的是表结构本身，不是连接配置；混淆这两者会导致排查方向完全错误
- 如果应用层也连着同一库，记得同步检查应用连接字符串里的
charset参数，避免插入乱码掩盖真实问题
