mysql报错1093是innodb引擎层对同一表既读又写的主动拦截，防止next-key lock冲突或自锁；根本原因在于事务中update需加x锁而子查询select可能触发读锁，导致数据不一致或死锁风险。
MySQL报错1093不是语法错误，而是引擎级保护机制
当你写 UPDATE t SET x = 1 WHERE id IN (SELECT id FROM t WHERE y = 2)，MySQL直接拒绝执行，并抛出 Error 1093 (HY000): You can't specify target table 't' for update in FROM clause。这不是解析器认不出语法，而是InnoDB在语句预处理阶段就主动拦截——它不允许同一事务中对一张表既加X锁（UPDATE）又用SELECT读取（哪怕只是子查询），因为这会引发Next-Key Lock冲突或自锁风险。
为什么“读+写同一张表”会导致数据不一致？
假设你执行 UPDATE msg SET status = 'read' WHERE id IN (SELECT id FROM msg WHERE create_time ，MySQL无法确定子查询该读“更新前的快照”还是“已部分更新的新状态”。在可重复读隔离级别下，这种不确定性会破坏事务一致性；更糟的是，如果子查询条件含<code>status字段，还可能形成逻辑循环（比如先读到未更新行→更新→再读时漏掉刚改过的行）。
派生表嵌套为什么能绕过限制？
写成 UPDATE t SET x = 1 WHERE id IN (SELECT id FROM (SELECT id FROM t WHERE y = 2) AS tmp) 就能通过，关键在两层括号+别名：AS tmp 强制MySQL把内层结果当作派生表（derived table），即一个无名临时结果集，而非对原表t的直接引用。此时外层UPDATE操作的是t，子查询读的是tmp，物理上已隔离。
- 内层子查询可以含
JOIN、GROUP BY，但最终必须单列单行（否则触发Subquery returns more than 1 row） -
AS tmp别名不可省略，MySQL 5.7+ 会校验这个标识 - 如果内层没走索引，仍会全表扫描并加锁——别名只解决语法拦截，不解决性能锁问题
JOIN写法比派生表更值得优先考虑
当更新逻辑本质是“根据另一张表匹配赋值”，比如用orders更新users的last_order_time，直接写 UPDATE users u JOIN orders o ON u.id = o.user_id SET u.last_order_time = o.created_at 更高效。它避免了子查询路径，执行计划清晰，且能利用o.user_id上的索引快速定位。
- 不能写成
UPDATE users, orders SET ... WHERE users.id = orders.user_id—— 旧式逗号连接在某些版本仍可能触发1093 - 若需聚合（如取最新订单时间），先用子查询生成中间集再JOIN：
UPDATE users u JOIN (SELECT user_id, MAX(created_at) AS ts FROM orders GROUP BY user_id) tmp ON u.id = tmp.user_id SET u.last_order_time = tmp.ts - 确保
ON条件字段有索引，否则JOIN退化为嵌套循环+全表扫描
