PostgreSQL 支持 DELETE FROM ... USING ... WHERE 语法，但非标准 ANSI JOIN 删除；USING 必须紧接 FROM 后、WHERE 前，仅引入关联表用于过滤，不可省略 FROM 或删除 USING 表。
PostgreSQL 不支持 DELETE ... USING ... WHERE 的标准写法？
直接说结论：PostgreSQL 确实支持 DELETE ... USING，但它不是 ANSI SQL 那种“带 JOIN 的 DELETE”，而是用 USING 引入额外表来提供过滤条件或关联字段——本质是隐式 CROSS JOIN + WHERE 过滤。很多人误以为能像 MySQL 的 DELETE t1 FROM t1 JOIN t2 ON ... 那样写，结果报错 syntax error at or near "USING"，其实是语法位置错了。
正确语法结构：DELETE FROM 表名 USING 其他表 WHERE 关联条件
USING 必须紧跟在 FROM 之后、WHERE 之前，且只能出现在 DELETE FROM 形式中（不能省略 FROM）。目标删除表必须显式写在 FROM 后，USING 后的表仅用于关联，不能被删。
DELETE FROM orders USING customers WHERE orders.customer_id = customers.id AND customers.status = 'inactive';- 如果漏掉
FROM（如DELETE orders USING ...），会报错syntax error at or near "USING" -
USING可接多个表，用逗号分隔：USING logs, users，但注意这是笛卡尔积起点，务必用WHERE严格限制连接条件，否则可能误删 - 别名只对
USING表生效，FROM表的别名在WHERE中不可用（PostgreSQL 14+ 支持，但低版本不推荐依赖）
替代方案：CTE 更安全、更易读
当逻辑复杂（比如要 JOIN 三张表、含子查询或聚合）时，USING 很快变得难维护。此时用 WITH CTE 预先筛选出待删 ID，再 DELETE ... WHERE id IN (SELECT ...) 更清晰，也避免隐式 JOIN 导致的意外匹配。
WITH target_ids AS ( SELECT o.id FROM orders o JOIN customers c ON o.customer_id = c.id JOIN subscriptions s ON c.id = s.customer_id WHERE c.status = 'archived' AND s.ended_at < NOW() - INTERVAL '1 year' ) DELETE FROM orders WHERE id IN (SELECT id FROM target_ids);
- CTE 方式天然防止因漏写
WHERE条件导致全表删除（USING下若忘记加关联条件，会变成 CROSS JOIN，后果严重） - 可独立测试 CTE 查询结果，验证逻辑是否符合预期
- 对大表，
IN (SELECT ...)可能比USING慢，但可通过EXISTS优化：WHERE EXISTS (SELECT 1 FROM target_ids t WHERE t.id = orders.id)
容易踩的坑：USING 不等于 JOIN，且不支持 USING (col) 简写
PostgreSQL 的 USING 在 DELETE 中和 JOIN 中的语义完全不同——这里它只是引入表名，不自动推导连接列，也**不支持**类似 JOIN ... USING (id) 的列名简写。所有关联都必须显式写在 WHERE 中。
- 错误写法：
DELETE FROM t1 USING t2 USING (id)→ 语法错误 - 错误写法：
DELETE FROM t1 USING t2 WHERE t1.id = t2.id却漏了t2.status = 'old'→ 可能删掉本该保留的记录 - 如果
USING表有同名列（如两个表都有created_at），WHERE中必须加表前缀，否则报错column reference "created_at" is ambiguous - 事务中执行前，建议先用
SELECT COUNT(*)模拟：把DELETE FROM换成SELECT COUNT(*) FROM，保持USING和WHERE完全一致
多表删除真正麻烦的从来不是语法，而是确认“哪些行该删”——USING 给了快捷路径，但也放大了逻辑疏漏的风险。动手删之前，先跑一遍等价的 SELECT，比背熟语法重要得多。
