UPDATE JOIN时索引失效主因是ON字段类型不一致引发隐式转换，如INT与INT UNSIGNED、VARCHAR与CHAR、同VARCHAR但COLLATION不同（如_utf8mb4_0900_as_cs与_unicode_ci），导致优化器弃用索引而全表扫描；需用SHOW CREATE TABLE或information_schema.COLUMNS核对TYPE/CHARACTER SET/COLLATION，并同步修改且验证完整JOIN语句的EXPLAIN结果。
UPDATE JOIN 时索引失效，先看连接字段类型是否一致
UPDATE ... JOIN 查询变慢，EXPLAIN 显示 key 为 NULL，大概率不是 SQL 写错了，而是 ON 两边字段类型不一致触发了隐式转换——MySQL 无法用索引做严格比较，只能全表扫描匹配。
哪些类型不一致会直接让索引“消失”
看着都是整数或都是字符串，但底层不兼容，优化器就放弃索引。常见组合：
-
INT和INT UNSIGNED（如user.id是INT UNSIGNED，order.user_id是INT） -
VARCHAR和CHAR（尤其长度差异大时，隐式 pad/trunc 影响排序逻辑） - 同为
VARCHAR，但COLLATION不同（如utf8mb4_0900_as_csvsutf8mb4_unicode_ci） - 字符集相同但校对规则不同，哪怕只差一个后缀（
_ci和_cs），B+ 树比较结果不可控，索引禁用
怎么快速确认是不是类型惹的祸
别猜，直接查定义：
- 执行
SHOW CREATE TABLE table_a和SHOW CREATE TABLE table_b，逐字对比 JOIN 字段的TYPE、CHARACTER SET、COLLATION - 更准一点：查
information_schema.COLUMNS，例如：SELECT column_name, data_type, character_set_name, collation_name FROM information_schema.COLUMNS WHERE table_name IN ('orders', 'users') AND column_name = 'user_id'; - 看
EXPLAIN输出：possible_keys有值但key为NULL，且Extra出现Using where而非Using index，基本锁定类型/校对问题
改字段类型时最容易踩的坑
统一不是改一个地方就完事，必须同步、完整、验证：
- 只改
CHARACTER SET不改COLLATION，等于没改——MySQL 实际比对的是校对规则 - 用
MODIFY COLUMN时，必须显式写出CHARACTER SET xxx COLLATE yyy，漏掉任一都可能回退到默认值 - ALTER 过程会重建索引，大表耗时长、锁表久；若用
ALGORITHM=INPLACE，要确认存储引擎和 MySQL 版本支持（InnoDB 8.0+ 更稳） - 改完立刻
EXPLAIN原 UPDATE 语句，不能只查单表——JOIN 的路径是否走索引，只有在完整语句里才能验证
最隐蔽的点：外键字段即使没写在 ON 条件里，只要存在约束，也会参与隐式校对比对。所以连外键列也得一起拉出来核对。
