在MySQL里，DELETE一旦直接配上引用目标表的子查询，基本就会触发1093错误。要绕开这层限制，通常得先包一层派生表，再给它起个别名，比如SELECT * FROM (...) AS tmp。PostgreSQL相对宽松一些，允许使用子查询，但同样不支持在子查询里再去引用正在删除的那张表。要是考虑跨库兼容，最好统一改用JOIN，而不是IN，这样既能避开NULL带来的坑，也更有利于性能表现。

DELETE 语句里直接套 SELECT 子查询会报错

MySQL 和 PostgreSQL 都支持在 DELETE 语句里配合子查询使用，但限制其实不少；SQLite 以及早期的 SQL Server，更是连“直接在 FROM 后面接子查询”这种写法都不认。实际开发里，最容易踩坑的，往往就是下面这种写法：

DELETE FROM users WHERE id IN (SELECT id FROM temp_blacklist);

这段在 MySQL 中通常可以正常执行；但如果放到 PostgreSQL 里，而子查询又恰好引用了目标表本身，比如 SELECT id FROM users WHERE status = 'inactive'，那就会直接报错： “cannot delete from table used in subquery”。

MySQL 中避免别名冲突的写法

MySQL 要求对子查询显式加别名，否则报 You can't specify target table for update in FROM clause。这不是语法错误，而是 MySQL 的限制机制：它禁止直接读写同一张表。

• 错误写法（触发报错）：

  DELETE FROM orders WHERE customer_id IN (SELECT customer_id FROM orders WHERE created_at < '2024-01-01');

• 正确写法（加别名绕过）：

  DELETE FROM orders WHERE customer_id IN (SELECT t.customer_id FROM (SELECT customer_id FROM orders WHERE created_at < '2024-01-01') AS t);

• 也可以改用 JOIN 形式，更清晰：

  DELETE o FROM orders o INNER JOIN orders o2 ON o.customer_id = o2.customer_id WHERE o2.created_at < '2024-01-01';

PostgreSQL 必须用 CTE 或 USING

PostgreSQL 不允许子查询引用正在删除的表，哪怕只是读取。必须拆成两步或改用标准语法。

• 推荐用 WITH（CTE）：

  WITH to_delete AS (SELECT id FROM users WHERE last_login < '2024-01-01') DELETE FROM users WHERE id IN (SELECT id FROM to_delete);

• 或用 USING 关联（适合多表逻辑）：

  DELETE FROM users u USING blacklisted b WHERE u.id = b.user_id;

• 注意：CTE 中的 SELECT 是执行时快照，不会受后续 DELETE 影响，这点和 MySQL 的嵌套子查询行为一致。

WHERE IN 子查询性能差时怎么办

当子查询返回上万行 ID，WHERE id IN (...) 可能触发全表扫描或临时表膨胀，尤其在没索引的字段上。

• 检查子查询字段是否建索引，比如 temp_blacklist(id) 或 users(status)；
• 把大子查询结果先写入临时表，再 JOIN 删除，MySQL 和 PG 都更可控；
• 避免在子查询里用 ORDER BY 或 LIMIT —— 它们对 DELETE 无意义，还拖慢解析；
• PostgreSQL 中若子查询含聚合（如 GROUP BY），确保 DELETE 条件能命中索引前缀，否则计划器大概率放弃索引。

实际执行前务必在测试库 BEGIN; DELETE ...; ROLLBACK; 跑一遍，特别是跨表关联删除时，外键约束和触发器可能产生意料外的级联动作。