UPDATE ... JOIN 变慢主因是驱动表选错和被驱动表缺索引：驱动表应选预估行数少的表，被驱动表关联字段（如orders.user_id）必须有索引，否则触发全表扫描。
Update 关联查询慢，90% 是驱动表选错 + 被驱动表缺索引，不是 SQL 写法本身的问题。
为什么 UPDATE ... JOIN 会变慢
MySQL 执行 UPDATE ... JOIN 时，本质上是按 JOIN 算法走的：先确定驱动表，再对被驱动表逐行匹配。如果被驱动表的关联字段没索引，就会退化成 Simple Nested-Loop Join，每条驱动表记录都触发一次全表扫描——1000 行驱动表 × 10 万行被驱动表 = 10 亿次行比较。
- 常见错误现象：
EXPLAIN UPDATE ... JOIN显示被驱动表的type=ALL，Extra为空或只有Using where - 真实瓶颈不在
UPDATE动作本身，而在 JOIN 匹配阶段 - 即使加了
LIMIT，也只限制最终更新行数，不减少匹配过程的扫描量
确保被驱动表关联字段有索引
这是最直接有效的优化点。被驱动表的 ON 条件列必须有单列索引或复合索引的最左前缀。
- 比如
UPDATE orders o JOIN users u ON o.user_id = u.id SET o.status = 'done'，则users.id必须是主键或有索引（通常已是），但更重要的是orders.user_id必须有索引——否则每次拿一个u.id去orders里找，都是全表扫 - 联合索引要注意顺序：
CREATE INDEX idx_user_status ON orders(user_id, status)可同时支撑WHERE user_id = ?和UPDATE ... SET status = ?，但idx_status_user就无法用于user_id查询 - 字符串关联字段（如
order_no）建议用前缀索引，避免索引过大：ALTER TABLE orders ADD INDEX idx_order_no (order_no(16))
用 EXPLAIN 验证驱动表是否合理
执行计划里的 table 列顺序就是实际驱动顺序，rows 值小的表应为驱动表。别默认“小表”是物理体积小的表。
- 运行
EXPLAIN SELECT * FROM orders o JOIN users u ON o.user_id = u.id WHERE u.status = 'active'（把 UPDATE 的逻辑先转成 SELECT 分析） - 若
users表rows=50、orders表rows=20000，但EXPLAIN显示orders在前，说明优化器误判——可能因为users.status没索引，导致它预估过滤后行数不准 - 强制指定驱动表：用
STRAIGHT_JOIN，例如UPDATE STRAIGHT_JOIN users u JOIN orders o ON u.id = o.user_id SET o.processed = 1 WHERE u.created_at -
possible_keys有值但key为NULL，大概率是类型不匹配（如INT对比VARCHAR）、隐式转换或函数包裹导致索引失效
替代方案：分步更新比 JOIN 更可控
当关联逻辑复杂、数据量大或无法加索引时，硬上 UPDATE ... JOIN 容易锁表、超时、拖垮从库。分步走更稳。
- 先查出目标 ID 列表：
SELECT o.id FROM orders o JOIN users u ON o.user_id = u.id WHERE u.status = 'pending' LIMIT 1000，确保该语句能走索引 - 再用
UPDATE orders SET status = 'done' WHERE id IN (1,2,3,...)—— 注意IN列表长度别超max_allowed_packet，一般控制在 1000 以内 - 批量处理时加
ORDER BY id和游标分页，避免重复处理：WHERE id > #{last_id} AND ... ORDER BY id LIMIT 1000 - 如果更新需依赖聚合结果（如 “每个用户最新订单”），先用临时表存中间结果，再关联更新，比子查询 + JOIN 更易命中索引
真正卡住性能的，往往不是那条 UPDATE 语句长得像不像教科书，而是你没看见驱动表怎么选、被驱动表有没有被索引兜住、以及 EXPLAIN 里 rows 那个数字背后的真实扫描量。
