update join 慢的核心原因是被驱动表关联字段无索引导致嵌套循环全表扫描，驱动表应选where过滤后行数少的表，且on字段必须有索引；可用explain验证、straight_join强制顺序，复杂场景宜改用临时表或分批更新。
UPDATE JOIN 为什么慢？关键在驱动表和索引
MySQL 的 UPDATE ... JOIN 不是“先 JOIN 再更新”，而是按 JOIN 算法执行：选一个驱动表，对每行去被驱动表匹配。如果被驱动表的关联字段没索引，就会变成嵌套循环全表扫描——1000 行驱动 × 10 万行被驱动 = 10 亿次行比对。
常见错误现象：EXPLAIN UPDATE ... JOIN 显示被驱动表的 type=ALL，Extra 为空或只有 Using where；即使加了 LIMIT，也只限制最终更新行数，不减少匹配过程的扫描量。
- 驱动表应选预估返回行数少的表（不是物理小的表），靠
WHERE条件过滤后的行数决定 - 被驱动表的
ON字段必须有索引——比如UPDATE orders o JOIN users u ON o.user_id = u.id，orders.user_id必须有索引，否则每次拿u.id去查orders都是全表扫 - 字符串关联字段（如
order_no）建议用前缀索引：ALTER TABLE orders ADD INDEX idx_order_no (order_no(16)) - 联合索引顺序很重要：
CREATE INDEX idx_user_status ON orders(user_id, status)能支撑WHERE user_id = ?和SET status = ?，但idx_status_user就不能用于user_id查询
如何验证并强制驱动表顺序
别信“小表驱动大表”的直觉，MySQL 优化器可能误判。先用 SELECT 模拟 JOIN 逻辑跑 EXPLAIN：
EXPLAIN SELECT * FROM orders o JOIN users u ON o.user_id = u.id WHERE u.status = 'active';
看 table 列顺序和各表的 rows 值。若 users 预估 50 行、orders 预估 20000 行，但 EXPLAIN 显示 orders 在前，说明优化器因 users.status 缺索引而低估了过滤效果。
-
possible_keys有值但key为NULL，大概率是类型不匹配（如INT对比VARCHAR）、隐式转换或函数包裹导致索引失效 - 用
STRAIGHT_JOIN强制顺序：UPDATE STRAIGHT_JOIN users u JOIN orders o ON u.id = o.user_id SET o.processed = 1 WHERE u.created_at ，确保 <code>users是驱动表
什么时候该放弃 UPDATE JOIN？
当关联逻辑复杂、数据量大、或无法给被驱动表加索引时，硬上 UPDATE JOIN 容易锁表、超时、拖垮从库。这时候分步更可控。
- 先用
CREATE TEMPORARY TABLE temp_update SELECT ...把要更新的 ID 和新值存下来，再UPDATE t JOIN temp_update ...——避免重复计算，且临时表天然有主键索引 - 用
INSERT INTO ... ON DUPLICATE KEY UPDATE替代：把目标数据写进临时表，再通过唯一键合并，全程不触发触发器、不走 JOIN 匹配路径 - 对百万级更新，优先考虑
CASE WHEN单条语句（适合离散 ID 更新）或分批LIMIT（如每次 5000 行），而不是依赖 JOIN 一次刷完
触发器会让批量 UPDATE 彻底失控
如果目标表上有触发器，UPDATE ... JOIN 或分批 LIMIT 都救不了你——10 万行更新 = 10 万次触发器调用，天然串行，无法跳过。
- 哪怕触发器只有一行
NEW.updated_at = NOW()，高并发下也会因系统时钟争用累积延迟 -
SHOW PROCESSLIST里大量线程卡在Updating状态，慢查询日志里同一条语句反复出现且耗时稳定在几毫秒以上，基本就是触发器在拖后腿 - 真正有效的办法是绕开触发器：用生成列（
DATETIME AS (NOW()) STORED）、应用层显式传参、或异步 BINLOG 解析替代
最常被忽略的一点：索引建对了、驱动表指定了、语句也拆批了，但如果表上挂着触发器，所有优化都白做——它不看执行计划，只认行数。
