子查询锁表时间过长，是因为mysql（尤其5.7前）将内层子查询物化为临时表，需扫描基表、加锁并写磁盘，且锁持续至外层语句结束；即使只更新1行，也可能先锁住10万行。
子查询锁表时间过长，不是语法写错了，而是它在执行过程中触发了比预期更重、更久的锁——尤其在 UPDATE 或 SELECT FOR UPDATE 场景下，锁可能从几行蔓延到几万行，甚至整张表。
为什么子查询会让锁持续那么久
关键不在“子查询”这个词本身，而在 MySQL（尤其是 5.7 及之前）对它的物化行为：内层子查询常被当成临时表生成，这个过程要扫描基表、加锁、写磁盘；而锁一旦加上，就一直持有到整个外层语句结束。哪怕你只更新 1 行，也可能先锁住 10 万行来算中间结果。
-
EXPLAIN显示DEPENDENT SUBQUERY或MATERIALIZED：前者表示每行主表都重跑一次子查询，高危；后者虽只算一次，但物化过程仍可能锁全量扫描范围 - 常见报错：
Lock wait timeout exceeded、Deadlock found when trying to get lock，但单独跑子查询或主查询却很快 - 典型陷阱：用
ORDER BY created_at DESC LIMIT 1在子查询里取最新记录，MySQL 8.0 以前无法下推，只能全表扫+排序+锁
用 JOIN 替代 IN/EXISTS 子查询时要注意什么
JOIN 不是万能解药，写错反而锁得更狠。核心是控制锁的粒度和范围，而不是单纯换写法。
- 把
UPDATE t1 SET x=1 WHERE id IN (SELECT id FROM t2 WHERE status=0)改成UPDATE t1 JOIN t2 ON t1.id = t2.id SET t1.x = 1 WHERE t2.status = 0—— 前提是t2.id是主键或唯一键，否则可能误更新多行 - 如果子查询含聚合（如
GROUP BY user_id），必须先用 CTE 或派生表聚合出结果，再 JOIN，否则JOIN会放大主表行数 -
NOT IN改LEFT JOIN ... WHERE right.id IS NULL时，若right.id允许为NULL，必须补上AND right.id IS NOT NULL，否则逻辑错误 - 确保连接字段都有索引：比如
t1.user_id和t2.id都要有对应索引，否则 JOIN 变成嵌套循环+全表扫
哪些子查询必须拆到应用层
当数据库优化器已经无力安全下推条件时，硬压在 SQL 层只会让锁竞争更隐蔽、更难收敛。
-
EXPLAIN显示Using temporary; Using filesort，且rows值远超实际返回行数 - 子查询里用了窗口函数（如
ROW_NUMBER() OVER ()）、GROUP_CONCAT、自定义函数 - 子查询含
ORDER BY ... LIMIT，且外层还要 JOIN 或聚合（此时索引排序大概率失效） - 跨库或跨分片查询，比如订单在分库，用户在主库，MySQL 无法协调分布式锁
事务边界模糊才是最隐蔽的锁延长器
很多“子查询锁太久”的问题，根源其实是事务没及时结束——锁时间 = 从 BEGIN 到 COMMIT 的整个窗口，不是 SQL 执行那几毫秒。
- Django 的
@transaction.atomic如果包裹了 HTTP 调用或文件处理，网络延迟直接拖长锁持有时间 - Spring 的
@Transactional默认传播级别是REQUIRED，嵌套调用可能意外延长事务生命周期 - 连接池复用后，前一个请求没
commit，下一个请求接着用同一连接 → 锁挂着没人收 - 查
SHOW ENGINE INNODB STATUS里的trx_started时间戳，结合SHOW PROCESSLIST定位线程，比看慢日志更快
真正卡住系统的，往往不是某条 SQL 多慢，而是它把锁挂在那里不动——等它释放，其他所有依赖这行数据的操作都得排队。所以优化重点从来不是“怎么让子查询跑快点”，而是“怎么让它少锁、快放、别拖”。
