MySQL禁止DELETE中直接子查询引用目标表，需用派生表加别名绕过；如DELETE FROM orders WHERE id IN (SELECT id FROM (SELECT id FROM orders WHERE created_at < '2023-01-01') AS tmp)。
DELETE 中用子查询匹配目标行，必须加别名
MySQL 8.0+ 和 PostgreSQL 支持 DELETE ... FROM ... WHERE ... IN (SELECT ...)，但直接写 SELECT id FROM orders WHERE status = 'cancelled' 在 DELETE 中会报错：「You can't specify target table for update in FROM clause」——这是 MySQL 的限制，不是语法写错。根本原因是 MySQL 禁止在同一个语句中对同一张表既查又删。
绕过方式是给子查询加显式别名，让优化器认为它是“临时表”：
DELETE FROM orders
WHERE id IN (
SELECT id FROM (
SELECT id FROM orders WHERE created_at < '2023-01-01'
) AS tmp
);- PostgreSQL 不需要这层包装，但加了也不报错，建议统一加上便于跨库迁移
- 别名
tmp不能省略，否则 MySQL 仍报错 - 子查询里不能有
ORDER BY或LIMIT（除非配合OFFSET，但多数场景不适用）
用 JOIN 替代 IN 子查询，避免 NULL 和性能陷阱
IN (SELECT ...) 遇到子查询结果含 NULL 时，整条 WHERE 判断会变成 UNKNOWN，导致零行被删——这不是 bug，是 SQL 三值逻辑的必然行为。更隐蔽的是，当子查询返回上万行时，IN 可能退化成嵌套循环，比 JOIN 慢一个数量级。
推荐改写为 DELETE ... USING（PostgreSQL / MySQL）或 DELETE ... FROM ... JOIN（MySQL）：
-- MySQL 写法 DELETE o FROM orders o INNER JOIN users u ON o.user_id = u.id WHERE u.last_login < '2022-06-01';
- JOIN 显式声明关联逻辑，NULL 值天然被过滤，无需额外
IS NOT NULL - 数据库能走索引合并或哈希连接，尤其当
users.last_login有索引时 - SQL Server 用
DELETE t FROM table t INNER JOIN ...，语法略有不同，但思路一致
删除前必须做安全备份：用 CREATE TABLE ... AS SELECT 而非 mysqldump
线上执行批量删除前，没人敢赌“WHERE 条件绝对准确”。用 mysqldump 备份整表太重，恢复也慢；而 CREATE TABLE backup_orders_20240501 AS SELECT * FROM orders WHERE created_at 是秒级操作，且只存要删的数据。
- 备份表自动继承原表字段类型和 NULL 属性，但不继承索引、外键、注释——删完确认无误后再手动补
- 务必给备份表名加上时间戳，避免重复覆盖，例如
backup_orders_20240501_1423 - 如果磁盘空间紧张，可加
WHERE 1=0先建空表结构：CREATE TABLE backup_orders LIKE orders
大表删除卡住或锁表？拆成小批次 + 加 LIMIT
一次性删 50 万行，InnoDB 会持有长时间的行锁甚至间隙锁，阻塞其他写操作，还可能触发 long transaction 报警。正确做法是分批删，每次最多 5000 行，并主动让出事务控制权。
MySQL 示例（需在支持 LIMIT 的 DELETE 中使用）：
DELETE FROM orders WHERE created_at < '2023-01-01' ORDER BY id LIMIT 5000;
- 必须带
ORDER BY（最好是主键），否则LIMIT行为不确定，可能漏删或重复删 - 执行后检查
ROW_COUNT()，若返回 0 说明删完了；否则休眠 100ms 再执行下一批 - 不要依赖存储过程自动循环——一旦中间出错，很难定位断点，用外部脚本（Python/Shell）更可控
真正麻烦的不是语法，是删完才发现 WHERE 条件少了个括号，或者时间范围写反了。备份表名带时间戳、每批删完立刻查 count，这两件事花不了三十秒，但能省掉半夜的 rollback。
