mysql delete语句中直接使用同一表的子查询会报错1093，因其禁止对目标表同时读写；需用派生表（如select * from (select ... from t) as tmp）或join方式绕过该限制。

DELETE 语句里直接套 SELECT 子查询做归档筛选，MySQL 会报错 “You can’t specify target table for update in FROM clause”——这不是语法写错了，是引擎限制：MySQL 不允许在同一个语句中对同一张表既查又删。

为什么 DELETE + 子查询在 MySQL 中会失败

MySQL 的执行顺序导致它无法安全地复用子查询结果来驱动主表的删除。哪怕你只是想“找出老数据再删”，只要 FROM log 出现在子查询里，就会触发错误。PostgreSQL 和 SQL Server 没这限制，但 MySQL 用户必须绕开。

• 常见错误现象：ERROR 1093 (HY000): You can't specify target table 'log' for update in FROM clause
• 本质不是逻辑错，而是 MySQL 优化器对自引用的保守策略
• 别试 SET sql_mode='' 或升级版本来“修复”——这是设计行为，不是 bug

两种可靠绕过方式：派生表 vs JOIN

核心思路是让 MySQL 把子查询结果当作临时中间集，切断与原表的直接引用关系。

• 用派生表包装（最直白）：DELETE FROM log WHERE id IN (SELECT id FROM (SELECT id FROM log WHERE created_at
• 改用 JOIN（性能更好，推荐）：DELETE l FROM log l INNER JOIN log l2 ON l.id = l2.id WHERE l2.created_at
• JOIN 写法天然避免全表扫描，如果 created_at 有索引，执行计划会走索引查找；而派生表在大表上可能被优化为临时表 + 全量扫描
• 注意别漏别名：DELETE l FROM log l ... 中的 l 必须声明，否则语法报错

归档不能只删不存：子查询只负责“筛”，不负责“搬”

嵌套查询本身不产生归档动作，它只是筛选条件的载体。真要归档，得拆成两步：先 INSERT INTO archive_table SELECT ...，再 DELETE。强行塞进一个语句里，要么失败，要么不可靠。

• 错误做法：INSERT INTO archive SELECT * FROM (SELECT * FROM log WHERE ...) AS tmp; DELETE FROM log WHERE ... —— 这两个语句之间存在时间窗口，新数据可能插入，导致漏归档或重复归档
• 正确做法：用事务包裹，或用 INSERT ... SELECT ... + DELETE 分批执行，并加 WHERE id BETWEEN x AND y 控制范围
• 别依赖子查询返回顺序：MySQL 不保证 SELECT 子查询的行序，若归档需按时间顺序处理，显式加 ORDER BY 并配合 LIMIT 分页（但注意 OFFSET 在大偏移时性能差）

容易被忽略的锁和性能陷阱

看似简单的子查询筛选，在高并发下可能引发严重阻塞，尤其当归档条件没走索引时。

• 如果 WHERE created_at 字段没索引，DELETE 会锁整张表（InnoDB 下是 next-key lock），业务写入全部卡住
• 派生表写法在 MySQL 5.7+ 可能触发 derived_merge=on 优化，又变回原始问题——可临时关掉：SET SESSION optimizer_switch='derived_merge=off';
• JOIN 写法若没明确关联条件（比如漏了 ON l.id = l2.id），会变成笛卡尔积，删光全表
• 归档量大时，别一次性删几百万行：分批执行，例如每次删 1 万行，用 WHERE id >= ? AND id 配合主键范围更稳定

真正决定归档成败的，从来不是子查询写得多漂亮，而是是否控制住锁粒度、是否避开 MySQL 特定限制、以及删之前有没有把数据稳稳落盘到归档表里。