mysql delete join语法合法但为特有语法，必须显式指定目标表别名（如delete t1 from t1 join t2 on...），漏写、错写或多写别名将导致误删或报错，且无交互确认。
DELETE JOIN 语法本身就会删错表
MySQL 的 DELETE JOIN 不是“用 JOIN 做条件”，而是“用 JOIN 构建可删行集合”，但它的目标表由 DELETE 后面显式列出的部分决定——漏写、写错、多写，结果天差地别。
-
DELETE FROM t1 JOIN t2 ON ...→ 报错ERROR 1064，语法不合法 -
DELETE t1, t2 FROM t1 JOIN t2 ON ...→ 真的会删两张表，哪怕你本意只动t1 -
DELETE t1 FROM t1 JOIN t2 ON t1.id = t2.ref_id→ 只删t1中能匹配到t2的行（即 INNER JOIN 结果） -
DELETE t1 FROM t1 LEFT JOIN t2 ON t1.id = t2.ref_id WHERE t2.ref_id IS NULL→ 删t1中在t2里没对应记录的行
问题不在逻辑难懂，而在于：写错一个字符（比如逗号、空格、别名），就可能从“删 50 行”变成“删 50 万行”或直接报错中断——且没有任何交互确认。
JOIN 条件字段没索引，删的不是数据而是锁
执行 DELETE t1 FROM t1 JOIN t2 ON t1.id = t2.ref_id 时，如果 t2.ref_id 没索引，MySQL 会全表扫描 t2，对每一行加临键锁（next-key lock）。哪怕你只删 1 行，t2 表所有主键间隙都被锁住，其他事务写入全部阻塞。
-
EXPLAIN SELECT * FROM t1 JOIN t2 ON t1.id = t2.ref_id中若出现type: ALL或key: NULL，说明该 JOIN 无索引可用 - 锁范围取决于扫描行数，不是删除行数；RR 隔离级别下，锁可能持续到事务结束
- 线上环境一旦触发，监控看到的是
innodb_row_lock_time_avg突增、Threads_running堆积，而不是“SQL 执行慢”
WHERE 条件写在 JOIN 外，却误以为它过滤了 JOIN 结果
很多人把 DELETE t1 FROM t1 JOIN t2 ON ... WHERE t2.status = 'cancelled' 当成“只删状态为 cancelled 的关联订单”，但实际执行逻辑是：先完成 JOIN，再对结果集应用 WHERE。如果 t2.status 没索引，或 t2 本身有几十万行，这个 WHERE 就成了全表扫描后的过滤——性能差、锁久、还容易因优化器选错驱动表而放大风险。
- 错误直觉：
WHERE是“提前剪枝”，其实它是“最后筛选” - 正确做法：确保
WHERE字段（如t2.status）有索引，且和ON字段构成联合索引前缀（例如(status, ref_id)） - 更稳妥的替代：改用
NOT EXISTS，把过滤逻辑下推到子查询中，避免 JOIN 膨胀
跨库迁移或读写分离时，语句根本跑不通
MySQL 的 DELETE JOIN 是私有语法，PostgreSQL、SQL Server、SQLite 全都不认。开发在 MySQL 主库验证通过的语句，一放到从库（只读）、PG 归档库、或新上线的 SQL Server 同步库，直接报错：
- PostgreSQL：syntax error at or near "JOIN"
- SQL Server：Msg 156, Incorrect syntax near the keyword 'INNER'
- SQLite：no such column 错误（因别名解析失败）
这时候临时改成子查询，又可能踩进 IN (SELECT ...) 在大结果集下的性能坑，或者被 MySQL 自己的 “不能指定目标表 for update in FROM clause” 限制卡住——真正危险的从来不是语法本身，而是你以为它“看起来像 SELECT 就很安全”。
