多表联合更新慢主因是关联字段无索引或索引未被使用；UPDATE JOIN比SELECT JOIN更易索引失效，因优化器更保守，常弃用ON字段索引致全表扫描；需用EXPLAIN模拟执行计划，关联字段及WHERE条件字段均须合理建索引，复合索引顺序应为等值条件→范围条件→连接字段。
多表联合更新慢，90%是因为关联字段没索引或索引没被用上——即使你写了 JOIN，MySQL 依然可能走全表扫描去匹配。
为什么 UPDATE JOIN 比 SELECT JOIN 更容易索引失效
UPDATE 语句的执行计划比 SELECT 更“保守”：优化器在评估成本时会更倾向避免复杂连接路径，尤其当 WHERE 条件弱、驱动表预估行数大时，它可能直接放弃使用 ON 字段上的索引，转而对右表做全表扫描（type: ALL）。这在 SELECT 中有时还能靠缓存掩盖，在 UPDATE 里却会立刻体现为锁等待和慢日志飙升。
- 执行前必须跑
EXPLAIN FORMAT=TREE UPDATE ...（MySQL 8.0+）或EXPLAIN SELECT ...对应逻辑——UPDATE 的执行计划不能直接 EXPLAIN，得用等价 SELECT 模拟 -
UPDATE t1 JOIN t2 ON t1.id = t2.t1_id SET t1.status = 'done'中，t1.id和t2.t1_id都要单独建索引；若t2还有WHERE t2.state = 'pending'，则需复合索引(state, t1_id) - 注意外键列 ≠ 索引列：
ALTER TABLE t2 ADD INDEX idx_t1_id (t1_id)必须显式执行，否则JOIN无法加速
复合索引顺序必须匹配 UPDATE 的过滤+连接逻辑
MySQL 5.7 的 B+ 树索引只能高效利用最左前缀。如果更新语句同时带过滤和连接，索引字段顺序错了，整个索引就废了一半。
- 典型错误写法：
UPDATE order o JOIN user u ON o.user_id = u.id SET o.processed = 1 WHERE u.level > 5 AND u.is_vip = 1—— 若给user表建了(is_vip, user_id)，但level > 5是范围查询，它必须放最后，否则user_id无法用于 JOIN 加速 - 正确复合索引应为：
(is_vip, level, id)：等值条件is_vip = 1在前 → 范围条件level > 5居中 → 连接字段id在末尾（供 JOIN 使用） - 如果
WHERE里还有ORDER BY u.created_at DESC，MySQL 5.7 无法用降序索引优化，此时要么去掉排序，要么接受filesort；别试图用(is_vip, level, id, created_at)强撑，created_at在范围后已失效
LEFT JOIN 更新时，左表必须先被有效过滤
MySQL 对 UPDATE ... LEFT JOIN 的驱动表选择几乎没有干预空间——左表固定为驱动表。如果左表没 WHERE 条件或条件选择性差，就会导致右表被反复扫描，锁住大量无关行。
- 避免写：
UPDATE t1 LEFT JOIN t2 ON t1.id = t2.t1_id SET t1.flag = 1（无 WHERE）—— 这等于全表更新t1，每行都触发一次t2全扫 - 必须前置强过滤：
UPDATE t1 LEFT JOIN t2 ON t1.id = t2.t1_id SET t1.flag = 1 WHERE t1.status = 'ready' AND t1.updated_at - 确保
t1.status和t1.updated_at已建联合索引，且status在前（等值），updated_at在后（范围） - 若业务允许，改用
INNER JOIN替代LEFT JOIN：只要求存在匹配才更新，天然规避空匹配开销
字段类型不一致会让索引彻底失效
哪怕两个字段都叫 user_id，只要一个是 INT、另一个是 BIGINT 或 VARCHAR(20)，MySQL 就会隐式转换，强制对其中一列做函数处理，索引立即作废。
- 检查方式：
SHOW CREATE TABLE t1;和SHOW CREATE TABLE t2;对比ON两侧字段的完整类型（含符号、长度、字符集） - 常见坑：
t1.user_id INT UNSIGNEDvst2.user_id INT（符号不一致）、t2.user_id VARCHAR(16)存的是字符串 ID（如 UUID）—— 这种设计本身就不该用于 JOIN，应统一为BINARY(16)或拆成独立映射表 - 修复不是加索引，而是改字段类型：
ALTER TABLE t2 MODIFY user_id INT UNSIGNED;，再补索引
真正卡住性能的，往往不是 JOIN 表的数量，而是某一张表的关联字段既没索引、类型又不一致、还被放在驱动侧——这种组合会让 UPDATE 锁住几百毫秒甚至几秒，且难以通过加内存或调缓冲池缓解。
