UPDATE多表关联慢主因是索引未建对或未用上，而非SQL写法错误；需用等价SELECT模拟EXPLAIN，重点看type和key字段，驱动表应最小，JOIN字段须单独建索引，避免隐式转换，优化器对UPDATE更保守易弃索引，有效提速手段包括拆分、临时表缓存和冗余字段。
UPDATE多表关联更新慢，90%不是SQL写得不对，而是索引没建对、没用上，或者优化器压根没走你期望的路径。
为什么EXPLAIN不能直接看UPDATE的执行计划
MySQL 5.7 不支持 EXPLAIN UPDATE；你直接执行会报错。必须用等价的 SELECT 模拟——把 UPDATE ... JOIN 改成 SELECT *，保持所有 JOIN 条件、WHERE 条件、表别名完全一致。
- 错误做法：
EXPLAIN UPDATE t1 JOIN t2 ON t1.id = t2.t1_id SET t1.status = 'done'→ 语法错误 - 正确做法：改写为
EXPLAIN SELECT t1.id FROM t1 JOIN t2 ON t1.id = t2.t1_id WHERE t1.status != 'done' - 重点看
type字段：如果出现ALL或index（非覆盖索引），说明右表在被全扫；key为空或不是你建的索引名，就是没用上 - 注意驱动表顺序：
EXPLAIN输出第一行是驱动表，它应是过滤后结果集最小的那个；否则嵌套循环次数爆炸
哪些字段必须建索引，顺序怎么排
不是“有JOIN就加ON字段索引”就够了。MySQL 5.7 的 B+ 树索引只认最左前缀，且 UPDATE 比 SELECT 更容易放弃索引。
-
JOIN条件两边的字段都要单独建索引：t1.id和t2.t1_id各自要有索引；外键约束 ≠ 索引，ALTER TABLE t2 ADD INDEX idx_t1_id (t1_id)必须显式执行 - 如果还有
WHERE t2.state = 'pending'，不要只建(state)单列索引；要建复合索引(state, t1_id)，让等值过滤和连接都能命中 - 若条件含范围查询（如
level > 5），索引顺序必须是：等值字段 → 范围字段 → 连接字段；例如(is_vip, level, id)，而不是(is_vip, id, level) - 避免隐式类型转换：比如
t2.t1_id是INT，但 JOIN 时写成t1.id = CAST(t2.t1_id AS CHAR)，索引直接失效
UPDATE JOIN比SELECT JOIN更容易慢的三个原因
同样一条 JOIN 逻辑，换成 UPDATE 后变慢，不是偶然——这是 MySQL 5.7 优化器的保守策略导致的。
- 优化器成本估算更激进：当预估驱动表返回行数较大（比如 > 1000 行），它倾向放弃使用
ON字段索引，转而对右表全表扫描，避免复杂连接路径带来的锁开销 - 没有查询缓存兜底：SELECT 可能靠 QCache 或 InnoDB 缓冲池掩盖低效，UPDATE 却必须真实写盘、加行锁，慢日志里立刻暴露
- 无法利用物化临时表：MySQL 5.6+ 的物化优化只对
SELECT生效；UPDATE 中子查询会被当作DEPENDENT SUBQUERY循环执行，性能雪崩 - 验证方式：对比
EXPLAIN SELECT和实际UPDATE的执行时间；如果后者慢 5 倍以上，基本可判定是优化器弃索引
真正有效的提速手段：拆、缓、冗余
硬扛索引优化到极限后，还慢？那就绕过 JOIN 本身。
- 拆成两步：先
SELECT出需要更新的主键列表（带LIMIT分批），再用UPDATE ... WHERE id IN (...)批量更新；应用层控制并发，避免单条 SQL 锁太久 - 用临时表缓存中间结果：比如
t2实际只用其中 0.1% 的数据，先CREATE TEMPORARY TABLE temp_t2 AS SELECT ... FROM t2 WHERE ...，再JOIN temp_t2；临时表默认走内存，速度远超磁盘表 - 加冗余字段：高频更新场景（如订单状态同步用户等级），在目标表
t1上冗余t2.status，用触发器或应用层双写维护；UPDATE 就退化成单表操作 - 慎用
STRAIGHT_JOIN：它能强制表顺序，但会关闭优化器自动选择；只在你 100% 确认驱动表且EXPLAIN验证有效时才加
最常被忽略的一点：UPDATE JOIN 的锁粒度是行锁，但若索引失效，就会升级成表锁或间隙锁，阻塞其他事务。别只盯着执行时间，还要看 SHOW ENGINE INNODB STATUS 里的 lock wait 信息。
