MySQL UPDATE子查询报错ERROR 1093本质是InnoDB锁机制保护：同一事务中UPDATE需加X锁而子查询SELECT可能触发Next-Key Lock，导致自锁风险；若子查询无索引则全表扫描并加锁，等效表锁。
UPDATE 里不能直接 SELECT 同一表，根本不是语法限制，而是锁机制冲突
MySQL 报错 ERROR 1093: You can't specify target table 't' for update in FROM clause，表面看是语法禁止，实际是 InnoDB 在执行时发现：同一个事务既要对表加 X 锁（UPDATE），又要读该表（子查询中的 SELECT），而读操作在默认隔离级别下可能触发 Next-Key Lock，导致自锁或死锁风险。解析器提前拦截，本质是保护机制。
子查询触发全表扫描时，行锁自动升级为表级效果
即使绕过语法限制（比如用派生表），只要子查询没走索引，优化器就会全表扫描——这时 UPDATE 实际会对所有被扫描的行加 Next-Key Lock。对百万级表，等于逻辑上“锁住整张表”，其他事务 UPDATE/DELETE 都会阻塞。这不是 bug，是 InnoDB 行锁依赖索引的必然结果。
-
UPDATE t SET a = 1 WHERE id IN (SELECT id FROM t WHERE status = 0)→ 若status无索引，SELECT全表扫描 →UPDATE对所有行加锁 - 改写为
UPDATE t SET a = 1 WHERE status = 0→ 只要status有索引，就只锁匹配行 - 若必须关联更新，优先用
JOIN：UPDATE t1 JOIN t2 ON t1.id = t2.id SET t1.a = t2.b，避免子查询路径
READ COMMITTED 能缓解但不解决子查询锁升级问题
在 READ COMMITTED 下，UPDATE 只加 Record Lock，不加 Gap Lock，锁范围变小。但子查询本身仍需读取数据，若没索引，依然全表扫描 + 全表 Record Lock —— 并发提升有限，锁等待时间未必缩短。真正起效的是让子查询走索引，而不是换隔离级别。
- 检查执行计划：
EXPLAIN SELECT id FROM t WHERE status = 0，确认是否用到索引 - 若
status是高频查询条件，加索引比调隔离级别更治本 -
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED仅对当前会话生效，别误设成全局
真正难防的是隐式锁依赖：UPDATE 等着另一个未提交事务刚 INSERT 的记录
比如事务 A 执行 INSERT INTO t VALUES (100, 'new') 但未提交，事务 B 的 UPDATE t SET x=1 WHERE id = 100 就会被阻塞——哪怕 id 是主键。这不是语法或配置问题，是业务逻辑中“先插后更”形成的隐式时序耦合。监控 INFORMATION_SCHEMA.INNODB_TRX 里的 TRX_STATE 和 TRX_WAITING 字段，比查错误日志更能暴露这类卡点。
