MySQL 原生支持 DELETE JOIN 语法（5.0+），其他主流数据库如 PostgreSQL、SQL Server、SQLite 均不支持；正确写法为 DELETE t1 FROM t1 JOIN t2 ON ... WHERE ...，须注意别名位置、LEFT JOIN 处理空值、外键约束及大表分批删除。
DELETE JOIN 语法在 MySQL 中才真正可用
其他数据库比如 PostgreSQL、SQL Server 或 SQLite 都不支持 DELETE ... JOIN 这种写法。MySQL 是少数原生支持该语法的主流数据库，但要注意版本——5.0+ 支持，8.0 后行为更严格（比如不能对被 JOIN 的表同时做子查询别名引用）。
典型错误是把 PostgreSQL 的 USING 或 SQL Server 的 FROM 写法直接套到 MySQL 里，结果报错 ERROR 1064 或 ERROR 1109。
- MySQL 正确写法：
DELETE t1 FROM orders t1 JOIN customers t2 ON t1.customer_id = t2.id WHERE t2.status = 'inactive' - PostgreSQL 等需改用
USING或 CTE：DELETE FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE status = 'inactive') - 别名必须出现在
DELETE后（如DELETE t1），否则 MySQL 会删错表甚至报错ERROR 1109: Unknown table
主从表关联删除时，WHERE 条件必须落在从表上才安全
如果你要清理“没有对应主记录”的从表数据（比如订单表里 customer_id 指向已删除客户），条件必须写在 JOIN 的 ON 子句或 WHERE 中明确指向从表的空值，而不是依赖主表过滤。
常见误操作是写成 DELETE o FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.id IS NULL ——这永远不生效，因为 JOIN 本身已排除了 c.id IS NULL 的行。
- 正确做法是用
LEFT JOIN+IS NULL：DELETE o FROM orders o LEFT JOIN customers c ON o.customer_id = c.id WHERE c.id IS NULL - 如果主表有软删除字段（如
is_deleted = 1），条件应写在 WHERE 里：WHERE c.is_deleted = 1，而不是 ON，否则可能漏删 - 执行前务必先用
SELECT验证：SELECT o.* FROM orders o LEFT JOIN customers c ON o.customer_id = c.id WHERE c.id IS NULL
外键约束会让 DELETE JOIN 失效或报错
如果从表上有 ON DELETE CASCADE，其实根本不需要手动写 DELETE JOIN —— 直接删主表就行。但若没设级联，又想批量清理，MySQL 会因外键检查失败而报 ERROR 1451: Cannot delete or update a parent row。
- 临时禁用外键检查只适用于开发/测试环境：
SET FOREIGN_KEY_CHECKS = 0;，删完立刻恢复：SET FOREIGN_KEY_CHECKS = 1; - 生产环境更稳妥的做法是先删从表，再删主表；或者用存储过程分批处理，避免锁表太久
- 注意：禁用外键检查不会跳过唯一索引或触发器，那些仍会生效
大表删除必须加 LIMIT 和循环，否则容易锁表或 OOM
一次性删几十万行，MySQL 会持有全表写锁（尤其 MyISAM），InnoDB 虽然行级锁，但事务日志暴涨、binlog 巨大，可能导致主从延迟甚至连接超时。
- 加
LIMIT分批删：DELETE o FROM orders o LEFT JOIN customers c ON o.customer_id = c.id WHERE c.id IS NULL LIMIT 10000 - 配合
ROW_COUNT()判断是否删完，写个简单循环脚本（shell 或 Python）反复执行直到返回 0 - 避免在高峰期执行；如有二级索引未覆盖
customer_id，先确认执行计划是否走索引，否则会全表扫描
实际中最容易被忽略的是：没验证 LEFT JOIN 的 NULL 条件是否真的命中目标行——比如客户表用了逻辑删除但没在 JOIN 条件里体现，结果一条没删掉。
