MySQL优化器对UPDATE JOIN执行计划更保守，因预估锁开销和写放大风险而倾向低效但安全的全表扫描；需为被驱动表连接字段显式建索引，复合条件索引顺序须匹配ON子句，LEFT JOIN更新会强制左表驱动并扩大锁范围，分批单表更新更安全。
UPDATE JOIN 的执行计划比 SELECT 更保守
MySQL 优化器对 UPDATE 的成本评估更谨慎：它默认假设更新操作会带来更高锁开销和写放大风险，因此在连接路径选择上倾向“安全但低效”的策略。比如明明 t2.t1_id 有索引，EXPLAIN SELECT 显示走了 ref，但等价的 UPDATE t1 JOIN t2 ON t1.id = t2.t1_id 却可能退化成 type: ALL —— 因为优化器预估驱动表过滤后行数偏大，直接放弃使用被驱动表索引。
常见错误现象：Deadlock found when trying to get lock 或慢日志里出现大量 Rows_examined 远高于预期值。这不是语法问题，而是优化器主动规避复杂连接路径的结果。
ON 字段索引必须显式存在，外键不等于索引
ALTER TABLE t2 ADD CONSTRAINT fk_t1_id FOREIGN KEY (t1_id) REFERENCES t1(id) 只建了外键约束，不会自动创建索引。InnoDB 对 JOIN 中被驱动表的匹配字段（如 t2.t1_id）要求必须有可用索引，否则强制全表扫描。
- 即使
t1.id是主键（自带聚簇索引），t2.t1_id也必须单独建索引：CREATE INDEX idx_t1_id ON t2(t1_id) - 复合连接条件如
ON t1.a = t2.x AND t1.b = t2.y，需确保t2.x和t2.y要么各自有单列索引，要么合建联合索引，且顺序严格匹配ON中的字段顺序 - 字段类型必须完全一致：
t1.id是BIGINT UNSIGNED，t2.t1_id就不能是VARCHAR或带符号的BIGINT，否则触发隐式转换，索引失效
复合索引字段顺序必须服从执行逻辑，不是 WHERE 优先
MySQL 执行 UPDATE t1 JOIN t2 ON t1.id = t2.t1_id WHERE t2.status = 'pending' 时，流程是：先用 t1.id 去 t2 查匹配行，再对匹配结果做 WHERE 过滤。所以索引应以连接字段开头，而非过滤字段。
典型错误：CREATE INDEX idx_status_t1_id ON t2(status, t1_id) 看似合理，但实际只能加速 WHERE status = ?，无法用于 JOIN 匹配——因为 t1_id 不是最左前缀。
正确写法：CREATE INDEX idx_t1_id_status ON t2(t1_id, status)。如果还有范围条件如 status IN ('pending', 'processing')，则需把等值字段放前、范围字段放后，确保连接字段始终可被索引最左前缀命中。
LEFT JOIN 更新时左表无法被跳过，驱动表锁定不可控
UPDATE t1 LEFT JOIN t2 ON t1.id = t2.t1_id SET t1.processed = 1 中，t1 强制为驱动表，哪怕它没加 WHERE 条件，也会全表扫描并逐行尝试关联 t2。更危险的是：只要 t2 出现在 ON 子句中，InnoDB 就会对所有扫描到的 t2 行（包括间隙）加 S 锁，且这些锁要等到事务结束才释放。
这意味着：没有 WHERE 的 LEFT JOIN UPDATE 实际上锁住了整个 t2 表的潜在匹配范围，极易引发死锁或长事务阻塞。真正该检查的不是语法是否合法，而是“这个 LEFT JOIN 是否真的必要”——多数场景下，用子查询或分批单表更新更安全。
最容易被忽略的点：索引设计只解决“查得快”，但解决不了“锁得多”。哪怕所有字段都有索引，UPDATE JOIN 的锁行为仍由优化器动态决定，不可预测。生产环境里，宁可多跑几次 SELECT id + 分批 UPDATE ... WHERE id IN (...)，也不要依赖一条看似简洁的多表更新语句。
