MySQL中DELETE JOIN必须显式指定目标表别名，正确写法为DELETE t1 FROM t1 JOIN t2 ON 条件 WHERE 子句；执行前须用SELECT验证、加LIMIT分批、建好索引，并避免NULL导致的逻辑错误。
DELETE JOIN 语法在 MySQL 中怎么写才安全
MySQL 支持 DELETE ... JOIN 语法，但必须明确指定要删哪张表的行，否则会报错或误删。常见错误是漏写表别名或没加 FROM 子句前的表名。
- 正确写法：先写
DELETE t1（明确目标表），再写FROM t1 JOIN t2 ON ... - 不能只写
DELETE FROM t1 JOIN t2—— 这在 MySQL 8.0+ 会报ERROR 1064 - 如果关联条件涉及时间字段（如
created_at ），建议给该字段建索引，否则全表扫描极慢 - 执行前务必加
SELECT COUNT(*) FROM t1 JOIN t2 ON ...预估影响行数
示例：删掉所有 30 天内无对应订单的用户
DELETE u FROM users u
JOIN orders o ON u.id = o.user_id
WHERE o.created_at < DATE_SUB(NOW(), INTERVAL 30 DAY)
AND NOT EXISTS (
SELECT 1 FROM orders o2 WHERE o2.user_id = u.id AND o2.created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY)
);
用 EXISTS 替代 JOIN 删除时要注意子查询的关联逻辑
EXISTS 更适合“主表中不存在匹配副表新记录”的场景，比如删过期用户——不是因为没订单，而是因为**最近 30 天没新订单**。这时候用 JOIN 容易漏判或重复删。
-
NOT EXISTS子查询里必须引用外层表字段（如u.id），否则变成恒真/恒假 - 子查询中不要写
SELECT *，统一用SELECT 1，避免解析开销 - 如果子查询条件含函数（如
DATE(created_at)），会导致索引失效；应改写为范围查询：created_at >= '2024-01-01' - PostgreSQL 和 SQL Server 不支持
DELETE ... JOIN，NOT EXISTS是跨平台更稳的选择
示例：删掉所有最近 30 天无任何订单的用户
DELETE FROM users u
WHERE NOT EXISTS (
SELECT 1 FROM orders o
WHERE o.user_id = u.id
AND o.created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY)
);
WHERE 子句里混用 JOIN 和子查询容易踩的坑
有人会把 JOIN 写在 WHERE 里（如 WHERE u.id IN (SELECT user_id FROM orders ...)），这在大数据量下性能极差，且可能因 NULL 值导致结果意外为空。
-
IN (SELECT ...)遇到子查询返回NULL时，整行被跳过（三值逻辑），而NOT EXISTS对 NULL 安全 -
LEFT JOIN ... WHERE right_table.id IS NULL看似等价于NOT EXISTS，但若右表有多个匹配行，会产生笛卡尔积，删掉比预期多得多的行 - MySQL 5.7 默认开启
STRICT_TRANS_TABLES，但某些旧配置下JOIN删除未加别名仍可能静默失败 - 所有删除操作前，建议先用
BEGIN; ... ROLLBACK;包裹测试
跨数据库迁移时 DELETE 关联逻辑怎么保持一致
MySQL 的 DELETE t1 FROM t1 JOIN t2 在 PostgreSQL 中不合法，SQL Server 要用 DELETE t1 FROM t1 INNER JOIN t2，而 SQLite 只支持单表 DELETE + 子查询。
- 最通用写法是
NOT EXISTS，所有主流数据库都支持且语义一致 - 如果必须用 JOIN 且目标库是 PostgreSQL，得改写成
DELETE FROM t1 USING t2 WHERE t1.id = t2.t1_id AND ... - SQLite 不支持
DELETE ... JOIN，也不支持NOT EXISTS中的关联字段别名（如u.id），得用WHERE NOT EXISTS (SELECT 1 FROM orders WHERE user_id = users.id AND ...) - 别依赖
USING或FROM扩展语法，除非你确定部署环境唯一
真正难的不是写出能跑的语句，而是确认「删的是不是你心里想删的那批」——尤其是时间条件带函数、JOIN 多于两张表、或副表存在软删除标记时，很容易删多或删漏。
