子查询更新易扩大行锁范围，因优化器行为、RR隔离级别及索引缺失叠加导致gap lock覆盖整个扫描索引段；应优先用带索引的EXISTS替代IN，或改用UPDATE JOIN、手动分批物化等可控方案。
子查询更新（UPDATE ... WHERE id IN (SELECT ...)）在 MySQL 中极易扩大行锁范围，不是因为语句写得“错”，而是优化器行为 + 隔离级别 + 索引缺失三者叠加的结果。核心问题在于：它可能对子查询扫描的**全部索引路径加 gap lock**，哪怕只更新 1 行，也可能锁住几万行间隙。
为什么 IN 子查询会让锁范围爆炸
在 REPEATABLE READ 隔离级别下，MySQL 对未物化的子查询默认走嵌套循环（DEPENDENT SUBQUERY），每匹配一行外层记录，就重新执行一次子查询 —— 如果子查询没索引、或用了函数、或结果集未被物化（MATERIALIZED），InnoDB 就会为它扫描过的整个索引段加 shared next-key lock。这意味着：UPDATE orders SET status='shipped' WHERE user_id IN (SELECT id FROM users WHERE email LIKE '%@gmail.com') 可能锁住 users 表上所有 email 索引的间隙，而不仅限于命中用户。
- 用
EXPLAIN FORMAT=TRADITIONAL查子查询是否标记为DEPENDENT SUBQUERY；是的话，基本等于锁范围失控 -
users(email)若无索引，或用了UPPER(email)这类函数，索引失效，直接全表扫 + 全表间隙锁 - 子查询含
LIMIT、GROUP BY或窗口函数时，MySQL 强制禁用物化，退化为逐行重查
用 EXISTS 替代 IN 的真实效果与前提
EXISTS 不是银弹，它只在满足索引前提下才真正缩小锁范围。优化器会尝试半连接（semi-join），只探测存在性，不构造结果集，因此通常只对实际命中的索引记录加 record lock，不扩展到间隙 —— 但前提是关联字段必须走索引。
- 把
WHERE id IN (SELECT user_id FROM logs WHERE type = 'login')改成WHERE EXISTS (SELECT 1 FROM logs l WHERE l.user_id = t.id AND l.type = 'login') - 必须建联合索引
INDEX idx_user_type (user_id, type)，顺序不能颠倒；单列type索引无效 - 别写
SELECT *，用SELECT 1更轻量，旧版本 MySQL 对*解析略慢 - 如果
t.id和l.user_id类型不一致（比如一个是BIGINT、一个是INT），隐式转换会让索引失效，锁又回来
强制物化失败时的手动兜底方案
当子查询因语法限制无法被自动物化（如含 ORDER BY ... LIMIT 10），你就得自己控制执行节奏，避免每次外层都触发一遍子查询扫描。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 先用
SELECT id FROM users WHERE status = 'inactive' ORDER BY id拿到 ID 列表，应用层分批（比如每 500 个一组） - 拼成
UPDATE orders SET status = 'archived' WHERE user_id IN (101,102,...,500)，确保IN内 ID 有序且不超长（MySQL 默认max_allowed_packet限制） - 每批单独
COMMIT，释放锁；别包进一个大事务里 —— 否则锁持续时间 = 所有批次总耗时 - 如果源表不能加索引、又没法改业务逻辑，临时建一张带索引的中间表：
CREATE TABLE tmp_users AS SELECT id FROM users WHERE status = 'inactive'; CREATE INDEX idx_id ON tmp_users(id);，再用JOIN更新
UPDATE JOIN 比子查询更可控的锁边界
相比 WHERE ... IN (SELECT)，UPDATE ... JOIN 的锁行为更可预测：它只锁定参与 JOIN 的匹配行和被更新的目标行，不会额外扫描子查询整张表。
- 写成
UPDATE orders o JOIN users u ON o.user_id = u.id SET o.status = 'blocked' WHERE u.status = 'banned' - 确保
orders(user_id)和users(status)都有索引，否则 JOIN 会转为全表嵌套循环 - 若
users上status基数低（比如只有 active/inactive/banned），考虑加覆盖索引INDEX idx_status_id (status, id)，让 JOIN 走索引查找而非回表 - 注意：MySQL 5.7+ 对
UPDATE JOIN支持LIMIT，可进一步控批：... LIMIT 500，但需确认执行计划中type是ref或eq_ref，不是ALL
最易被忽略的一点：锁范围是否扩大，不取决于你写了什么 SQL，而取决于执行计划中它**实际扫描了哪些索引项**。哪怕语法完全一样，rows 值从 100 变成 10000，gap lock 范围就差两个数量级。所以每次上线前，务必用真实参数跑一遍 EXPLAIN，盯紧 type、key、rows 这三列。
