子查询阻塞SELECT本质是锁等待而非语法慢，常见于REPEATABLE READ下间隙锁、IN子查询未索引或依赖型执行；优化需用EXPLAIN分析执行计划，优先改JOIN、加合适索引并验证。
子查询导致 SELECT 被阻塞，本质是锁等待
不是子查询语法本身慢，而是它触发了行锁或间隙锁，让其他事务卡在 SELECT ... FOR UPDATE 或 UPDATE 上。常见现象是：一个事务正在执行含子查询的更新，另一个只读 SELECT 却迟迟不返回——说明它在等锁，而不是在等执行。
- MySQL 默认隔离级别
REPEATABLE READ下，子查询若走索引范围扫描，可能加间隙锁（Gap Lock），锁住不存在的记录位置 - 子查询里用了
IN (SELECT ...)且外层语句是UPDATE/DELETE，MySQL 5.7+ 会转成半连接（semi-join），但若子查询结果集大、没走索引，仍会临时锁住大量记录 - PostgreSQL 没有间隙锁，但子查询若带
FOR UPDATE或出现在UPDATE ... FROM中，会按实际扫描的行加行级锁，同样引发阻塞
用 EXPLAIN 看清子查询是否真的“被展开”
很多人以为写成子查询就一定比 JOIN 慢，其实优化器常会重写。关键是看执行计划里有没有 DEPENDENT SUBQUERY 或 MATERIALIZED ——前者表示每次外层行都重执行一次子查询（高危），后者表示只算一次（较安全）。
- MySQL 中运行
EXPLAIN FORMAT=TRADITIONAL，重点看select_type列：出现DEPENDENT SUBQUERY就得警惕 - PostgreSQL 用
EXPLAIN (ANALYZE, BUFFERS)，关注子查询是否出现在SubPlan里，以及是否重复执行（Actual Loops > 1） - 如果子查询里有
LIMIT或ORDER BY，MySQL 8.0+ 可能无法物化，强制回退为依赖型执行
把 IN 子查询改成 JOIN 通常能绕过锁升级
IN (SELECT id FROM t2 WHERE ...) 在更新场景下容易触发全表扫描+锁膨胀；换成 JOIN 后，优化器更可能用索引驱动，锁的粒度也更可控。
- 把
UPDATE t1 SET x=1 WHERE id IN (SELECT t2.id FROM t2 WHERE t2.status=0)改成：UPDATE t1 INNER JOIN t2 ON t1.id = t2.id SET t1.x = 1 WHERE t2.status = 0
- 注意：JOIN 写法要求
t2.id是唯一键或主键，否则可能误更新多行；而IN天然去重，这点要手动补DISTINCT或加GROUP BY - SQL Server 中类似问题更明显：
IN子查询可能触发表扫描并持有共享锁（S 锁），阻塞写入；EXISTS通常更轻量，但也要看是否能走索引
加索引不是万能解，得看子查询的谓词是否能命中
给子查询字段加索引后还是慢？大概率是谓词没落在索引最左前缀上，或者用了函数/隐式转换，导致索引失效。
- 子查询中写
WHERE created_at > DATE_SUB(NOW(), INTERVAL 7 DAY)，即使created_at有索引，也可能因计算表达式无法使用索引范围扫描 - PostgreSQL 中
WHERE status::text = 'active'会跳过status的普通索引，需建函数索引：CREATE INDEX ON t2 ((status::text)) - MySQL 8.0+ 支持不可见索引，上线前可用
ALTER TABLE t2 ALTER INDEX idx_status INVISIBLE快速验证是否真有用
真正难处理的是子查询嵌套三层以上、又跨库或含窗口函数的场景——这时候锁行为已经脱离直觉，必须结合 INFORMATION_SCHEMA.INNODB_TRX 和 sys.innodb_lock_waits 实时抓锁链。别指望调个参数就解决。
