MySQL 5.7 中 UPDATE JOIN 易锁全表，因被驱动表关联字段无索引时触发全表扫描与临键锁；需确保 ON 字段有合适索引、避免多表 WHERE 混用、慎用 LEFT JOIN，且必须通过 EXPLAIN 验证执行计划。
UPDATE JOIN 为什么一执行就锁住整张表
不是语法写错了，是 MySQL 5.7 在 UPDATE ... JOIN 执行时默认走全表扫描 + 临键锁（next-key lock），只要被驱动表没走索引，InnoDB 就会逐行加锁——哪怕你只打算改 1 行，它也可能锁住几千行甚至整个索引区间。
- 驱动表（
JOIN左侧）满足WHERE条件的每一行，都会触发对被驱动表（右侧）的匹配扫描；若被驱动表关联字段（如t2.user_id）无索引，就会全表扫 - 全表扫描过程中，InnoDB 对每个扫描到的行加记录锁，同时对其左侧间隙加间隙锁 → 合起来就是临键锁，范围远超实际匹配行
-
REPEATABLE READ隔离级别下，这种锁不会随语句结束释放，而是持续到事务提交，极易阻塞后续SELECT ... FOR UPDATE或其他UPDATE - EXPLAIN 看不到锁行为，但可通过
SHOW ENGINE INNODB STATUS中的HOLDS THE LOCK(S)和WAITING FOR THIS LOCK TO BE GRANTED对照确认
ON 条件字段没索引 = 主动开闸放锁
外键约束不等于索引，FOREIGN KEY 只保证引用完整性，不提供查询加速。被驱动表的 ON 字段必须显式建索引，否则优化器直接放弃使用该路径，退化为 type: ALL。
- 错误示例：
UPDATE orders o JOIN users u ON o.user_id = u.id，若users.id是主键（OK），但orders.user_id没索引 →orders成为被驱动表，全表扫描 - 正确做法：在
orders.user_id上建索引，如CREATE INDEX idx_user_id ON orders(user_id) - 复合条件如
ON t1.a = t2.x AND t1.b = t2.y，必须确保t2.x是联合索引最左前缀，例如INDEX idx_x_y (x, y)，而非(y, x) - 字段类型不一致也会让索引失效：比如
t1.id是BIGINT UNSIGNED，而t2.t1_id是VARCHAR，隐式转换导致无法命中索引
WHERE 条件混用多表字段，锁范围指数级膨胀
MySQL 5.7 的 UPDATE JOIN 不支持在 WHERE 中安全地混合过滤多张表的字段。一旦出现类似 WHERE o.status = 'pending' AND u.country = 'CN'，优化器大概率放弃所有索引，直接全表扫两张表。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 根本原因：优化器对
UPDATE JOIN的成本估算更保守，认为跨表条件难以精确剪枝，宁可全扫也不冒险走部分索引 - 现象：慢日志中
Rows_examined远高于实际匹配数，EXPLAIN显示type: ALL或key: NULL - 解法不是加索引，而是拆逻辑：先用
SELECT o.id FROM orders o JOIN users u ON ... WHERE ...拿到目标id列表（确保该语句能走索引），再用UPDATE orders SET ... WHERE id IN (...) - IN 列表别超 1000 个值，否则可能触发临时表或优化器误判；分批时每批仍需按
id升序排列，避免死锁
LEFT JOIN 更新会让左表“裸奔”加锁
UPDATE t1 LEFT JOIN t2 ON ... 强制 t1 为驱动表，且即使 t1 上没有任何 WHERE 条件，也会全表扫描并逐行尝试关联 t2 —— 这意味着 t1 每一行都被加上 X 锁，完全失去并发性。
- 典型陷阱：想“标记所有订单为已处理”，写成
UPDATE orders o LEFT JOIN order_items oi ON o.id = oi.order_id SET o.processed = 1，结果锁住全部订单行 - 没有
WHERE的LEFT JOIN更新，等价于全表更新，锁范围和UPDATE orders SET ...一样大 - 如果业务真需要“补漏”式更新，应改用带明确范围的子查询：
UPDATE orders SET processed = 1 WHERE id IN (SELECT DISTINCT order_id FROM order_items)，并确保子查询能走索引 - 注意：子查询必须加
LIMIT 1（若用于SET赋值），否则报错ERROR 1242
复杂点在于，锁范围是否扩大，不取决于你写了什么条件，而取决于执行计划是否真的用了索引。很多看似“合理”的写法，在 5.7 下会被优化器主动降级——所以不能只看 SQL，得盯紧 EXPLAIN FORMAT=TRADITIONAL 的 key 和 type 字段。
