MySQL 5.7及更早版本禁止DELETE的WHERE中直接子查询引用目标表，因引擎限制导致报错ERROR 1093；PostgreSQL/SQL Server虽支持但存在快照语义歧义，故推荐用CREATE TEMPORARY TABLE先物化ID再JOIN删除，实现逻辑解耦与安全高效。
为什么不能直接用子查询做 DELETE 的 WHERE 条件？
MySQL 5.7 及更早版本会报错 ERROR 1093 (HY000): You can't specify target table 't1' for update in FROM clause，因为引擎不允许在 DELETE 的 WHERE 子句里直接 SELECT 同一张表。PostgreSQL 和 SQL Server 虽然支持，但语义容易歧义——比如子查询是否该基于删除前还是删除后的快照。临时表绕开了这个限制，也避免了重复计算。
CREATE TEMPORARY TABLE + DELETE JOIN 是最稳妥的组合
临时表只在当前会话可见、自动清理，适合中等规模（几万到百万行）的批量删除。关键不是“建表”，而是让过滤逻辑和删除动作解耦：
CREATE TEMPORARY TABLE temp_ids AS SELECT id FROM orders WHERE status = 'cancelled' AND created_at-
DELETE o FROM orders o INNER JOIN temp_ids t ON o.id = t.id（MySQL 语法） - PostgreSQL 写法：
DELETE FROM orders WHERE id IN (SELECT id FROM temp_ids)，但注意IN在百万级时可能慢于USING - 务必给
temp_ids.id加索引：CREATE INDEX idx_temp_id ON temp_ids(id)，否则 JOIN 或 IN 查找退化为全表扫描
DELETE 操作前必须验证临时表内容
临时表建错或条件写反会导致误删。别跳过这步：
- 先执行
SELECT COUNT(*) FROM temp_ids看数量是否合理 - 再查几条样例：
SELECT * FROM temp_ids LIMIT 5，确认id确实是你想删的那些 - 如果原始表有外键，临时表没包含关联字段，后续
DELETE可能触发级联或报错，需提前检查约束 - 生产环境建议加事务：
BEGIN; CREATE TEMPORARY TABLE ...; DELETE ...; SELECT ROW_COUNT(); ROLLBACK;测试完再把ROLLBACK换成COMMIT
大表删除要防锁表和日志膨胀
一次删几百万行会让 orders 表长时间处于写锁状态，binlog 或 WAL 日志暴涨。临时表本身不解决这个问题，但提供了分批基础：
- 在临时表里加自增序号：
CREATE TEMPORARY TABLE temp_ids AS SELECT id, @row:=@row+1 AS rn FROM orders JOIN (SELECT @row:=0) r WHERE ... - 然后分批删：
DELETE o FROM orders o INNER JOIN temp_ids t ON o.id = t.id WHERE t.rn BETWEEN 1 AND 10000 - 每批后加
SLEEP(0.1)（MySQL）或pg_sleep(0.1)（PG），缓解主从延迟和 I/O 压力 - InnoDB 下，单次 DELETE 超过 10 万行建议拆分，否则 undo log 可能撑爆
ibdata1
临时表不是银弹——它把问题从“语法限制”转向“资源控制”，真正难的是判断该删多少、何时停、怎么监控影响。别依赖一条 DELETE 跑完，盯住 SHOW PROCESSLIST 和磁盘 IO 才算落地。
