EXCEPT不能直接用于DELETE，必须用子查询包裹；它仅是集合运算符，需嵌套为子查询才能作为DELETE的条件来源，且多列匹配须用元组语法。
EXCEPT 不能直接用于 DELETE，必须用子查询包裹
SQL 标准中 EXCEPT 是集合运算符，只返回结果集，不支持直接跟在 DELETE 后面（比如 DELETE FROM t1 EXCEPT SELECT * FROM t2 会报错）。想删掉「存在于表 A 但不存在于表 B」的记录，得把 EXCEPT 的结果作为条件来源，常见做法是用 WHERE (col1, col2, ...) NOT IN 或 NOT EXISTS，但若要严格复用 EXCEPT 逻辑，必须嵌套为子查询。
- PostgreSQL、SQL Server、SQLite 支持
EXCEPT，但 MySQL 不支持（需改用LEFT JOIN ... IS NULL或NOT EXISTS） - 列数、数据类型、顺序必须完全一致，否则
EXCEPT报错或结果不可靠 - 注意
EXCEPT默认去重，如果源表有重复行且你希望保留语义上的“逐行差异”，它会静默丢弃重复 —— 这时更适合用NOT EXISTS配合主键/唯一约束
安全删除：先用 EXCEPT 预览，再套进 DELETE
千万别跳过验证。先运行 EXCEPT 查出待删数据，确认无误后再构造 DELETE。以删除 users 中「邮箱不在白名单表 allowed_emails 中」的用户为例：
SELECT id, email FROM users EXCEPT SELECT user_id AS id, email FROM allowed_emails;
这个结果就是将被删除的行。接着把它转成安全可执行的 DELETE：
DELETE FROM users WHERE (id, email) IN ( SELECT id, email FROM users EXCEPT SELECT user_id AS id, email FROM allowed_emails );
- 多列匹配必须用元组语法
(col1, col2)，不是col1 IN (...) AND col2 IN (...)（后者逻辑错误） - PostgreSQL 支持元组
IN，SQL Server 要改用EXISTS+ 自关联，MySQL 则根本不能用EXCEPT，得彻底换写法 - 大表慎用：子查询中的
EXCEPT可能触发全表扫描，建议确保users(id,email)和allowed_emails(user_id,email)上有联合索引
替代方案：为什么 NOT EXISTS 往往更可靠
当遇到 EXCEPT 不支持或性能差的情况，NOT EXISTS 是更通用、更可控的选择，语义也更贴近“删掉 A 中那些在 B 中找不到匹配的记录”：
DELETE FROM users u WHERE NOT EXISTS ( SELECT 1 FROM allowed_emails a WHERE a.user_id = u.id AND a.email = u.email );
-
NOT EXISTS在所有主流数据库都支持，行为一致 - 可利用索引加速（只要
allowed_emails(user_id, email)有合适索引，效率远高于EXCEPT全量比对） - 能正确处理
NULL值：NOT IN遇到任意NULL就整个条件返回UNKNOWN，导致不删任何行 —— 这是线上事故高发点
跨库或导出场景：EXCEPT 适合做差异快照，不适合驱动 DML
如果你是在做数据同步、ETL 校验或生成变更报告，EXCEPT 是极佳的“差异快照工具”。例如导出仅存在于生产库但缺失于测试库的配置项：
SELECT name, value, env FROM prod_config EXCEPT SELECT name, value, 'test' FROM test_config;
但这类输出本质是只读比对。一旦需要“根据差异执行删除”，就立刻脱离 EXCEPT 能力边界 —— 它不提供行定位、事务控制或错误恢复机制。真正落地时，得靠主键+应用层判断，或用 NOT EXISTS 这类原生 DML 友好语法。
最常被忽略的一点：EXCEPT 的隐式排序和去重会改变原始行序和数量，而删除操作依赖精确的行标识。拿不到主键或唯一约束保障时，别指望靠 EXCEPT 输出直接驱动 DELETE。
