<p>MySQL DELETE语句中直接使用同一表的子查询会报错1093，因其禁止对目标表同时读写；需用派生表（如SELECT * FROM (SELECT ... FROM t) AS tmp）或JOIN方式绕过该限制。</p>
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 特定限制、以及删之前有没有把数据稳稳落盘到归档表里。
