SELECT ... FROM (SELECT ...) 本身不改变锁行为，实际加锁由外层SELECT的执行计划和隔离级别决定：RR下可能加next-key lock，RC下仅行锁。
SELECT ... FROM (SELECT ...) 会加什么锁？
嵌套查询本身不改变锁行为，真正起作用的是外层 SELECT 的执行计划和隔离级别。MySQL 在可重复读（RR）下，如果优化器决定走全表扫描或索引扫描，哪怕只是查子查询结果，也可能对涉及的行或间隙加 next-key lock；而读已提交（RC）下只加行锁，不锁间隙。
常见错误现象：SELECT * FROM orders WHERE id IN (SELECT order_id FROM refunds WHERE status = 'pending') 在 RR 下可能锁住整个 refunds 表的多个间隙，导致其他插入被阻塞。
- 用
EXPLAIN FORMAT=TREE看子查询是否物化（MATERIALIZATION），物化后外层扫描临时表一般不加锁 - 若子查询未物化、且关联字段无索引，MySQL 可能退化为嵌套循环 + 每次回表，锁范围扩大
- PostgreSQL 不同：子查询默认不加锁，除非显式写
FOR UPDATE或在可串行化级别下触发 SSI 检测
READ COMMITTED 下嵌套查询还会有幻读吗？
不会——但仅限于“外层查询”本身。RC 级别下每次快照读都取最新已提交版本，子查询执行时生成独立快照，外层再基于该结果过滤，所以不会看到新插入的行。但要注意：子查询和外层不是同一快照。
使用场景：报表类查询需要“尽量新”的中间结果，又不想锁太久，RC 是更安全的选择。
- MySQL 5.7+ 默认 RR，必须显式
SET TRANSACTION ISOLATION LEVEL READ COMMITTED - Oracle 没有 RR 级别，其
READ COMMITTED行为接近 MySQL 的 RC，嵌套查询天然不幻读 - SQL Server 的
READ COMMITTED SNAPSHOT（RCSI）开启后，所有读都不阻塞也不被阻塞，嵌套查询锁影响基本消失
WHERE EXISTS (SELECT 1 FROM ...) 的锁比 IN 更轻？
不一定，但通常更可控。因为 EXISTS 是半连接，只要找到一行就终止，优化器更容易利用索引快速退出；而 IN 子查询常被转成物化临时表，若没走哈希查找，后续匹配可能触发全扫描。
容易踩的坑：EXISTS 中的子查询若没走索引，MySQL 仍会对驱动表每行都执行一次全表扫描，锁住大量无关行。
- 确保
EXISTS子查询的WHERE条件有可用索引，尤其是关联字段 - 避免在
EXISTS里写SELECT *，虽然不影响锁，但可能误导优化器选择错误执行路径 - PostgreSQL 对
EXISTS优化更好，即使子查询无索引，也倾向用Anti Join而非嵌套循环
事务中混合 DML 和嵌套 SELECT 容易死锁
典型模式：UPDATE t1 SET x = x + 1 WHERE id IN (SELECT id FROM t2 WHERE flag = 1)。MySQL 会先锁 t2 中满足条件的行（用于子查询），再按顺序锁 t1 中对应行——如果两个事务以不同顺序访问 t2 和 t1，就构成循环等待。
性能影响明显：RR 下这种语句常触发 Lock wait timeout exceeded，尤其在高并发更新场景。
- 拆成两步：先
SELECT id INTO @ids FROM t2 WHERE flag = 1，再UPDATE t1 ... WHERE id IN (@ids)，但注意@ids是单值，批量需用临时表 - 用
JOIN重写：MySQL 对UPDATE t1 JOIN t2 ON ...的加锁顺序更确定，优先锁驱动表 - 避免在长事务里跑嵌套查询，特别是子查询涉及大表或慢条件——锁持有时间直线上升
最麻烦的其实是隐式锁升级：你以为只读，但子查询碰到了唯一索引的重复键检查，InnoDB 会悄悄加上 insert intention lock，和其他插入事务掐起来。这种锁看不见、日志里也不报，只能靠 SHOW ENGINE INNODB STATUS 抓现场。
