MySQL支持DELETE JOIN语法，PostgreSQL需用USING，SQL Server应用EXISTS；NULL会使IN失效，应优先用EXISTS；删除前必须SELECT验证，生产环境须事务包裹并处理外键依赖。
DELETE + JOIN 语法在不同数据库中的可用性
MySQL 支持 DELETE ... FROM ... JOIN，PostgreSQL 和 SQL Server 不支持直接 JOIN 删除，SQLite 仅支持单表 DELETE。别硬套 MySQL 写法到其他库，否则会报 ERROR: syntax error at or near "JOIN" 或类似错误。
实操建议：
- MySQL 可用：
DELETE t1 FROM users t1 JOIN temp_blacklist t2 ON t1.id = t2.user_id; - PostgreSQL 必须改用
USING子句：DELETE FROM users USING temp_blacklist WHERE users.id = temp_blacklist.user_id; - SQL Server 要用
EXISTS或IN（注意IN对 NULL 敏感）：DELETE FROM users WHERE EXISTS (SELECT 1 FROM temp_blacklist b WHERE b.user_id = users.id);
用 EXISTS 还是 IN？关键看子查询是否含 NULL
IN 在子查询结果包含 NULL 时会整体返回空集，导致删不掉任何数据——这是最常被忽略的静默失败点。
比如 SELECT * FROM users WHERE id IN (1, 2, NULL) 实际等价于 WHERE id = 1 OR id = 2 OR id = NULL，而 id = NULL 永远为 false，整个条件变成 false。
实操建议：
- 子查询明确过滤 NULL：
DELETE FROM users WHERE id IN (SELECT user_id FROM temp_blacklist WHERE user_id IS NOT NULL); - 更稳妥统一用
EXISTS，它不受 NULL 影响：DELETE FROM users WHERE EXISTS (SELECT 1 FROM temp_blacklist WHERE user_id = users.id); - 如果子表很大，
EXISTS通常比IN快，因为可提前终止；但需确保user_id字段有索引。
误删防护：永远先用 SELECT 验证删除范围
执行 DELETE 前不预查，等于闭眼踩雷。哪怕语句看起来很短，也可能因 JOIN 条件写错、字段名拼错、类型隐式转换，删掉整张表。
实操建议：
- 把
DELETE换成SELECT COUNT(*)或SELECT *先跑一遍：SELECT COUNT(*) FROM users WHERE EXISTS (SELECT 1 FROM temp_blacklist WHERE user_id = users.id); - 检查返回行数是否符合预期，再确认
temp_blacklist表数据是否最新、是否有重复或脏数据。 - 生产环境务必加事务包裹，并设好超时：
BEGIN; DELETE ...; -- 看结果，没问题再 COMMIT，否则 ROLLBACK;
外键约束下删除失败的典型表现和绕过方式
如果 users 是被引用表（比如订单表 orders 的 user_id 外键指向它），直接删会报 ERROR: update or delete on table "users" violates foreign key constraint。
不能靠 SET FOREIGN_KEY_CHECKS = 0（MySQL）或删约束来硬刚——这会破坏数据一致性。
实操建议：
- 先删子表关联数据：
DELETE FROM orders WHERE user_id IN (SELECT id FROM users WHERE EXISTS (SELECT 1 FROM temp_blacklist WHERE user_id = users.id)); - 再删主表：
DELETE FROM users WHERE EXISTS (...); - 或者用级联删除（需建表时定义
ON DELETE CASCADE），但上线后补加需重建外键，风险高，慎用。
实际执行时，最易出问题的是子查询 NULL 和外键依赖，这两处没验证，删完才发现订单、日志全断了。
