DELETE JOIN必须显式指定目标表，如DELETE u FROM users u JOIN orders o；执行前需用SELECT验证影响行数；大范围删除须分批加休眠；ON和WHERE字段须有索引，否则性能骤降。
DELETE JOIN 语句必须显式指定目标表
MySQL 的 DELETE JOIN 不像 SELECT JOIN 那样默认作用于所有表。如果你写成 DELETE FROM users JOIN orders...，MySQL 会报错：ERROR 1064 (42000): You have an error in your SQL syntax。必须明确写出要删哪个（或哪些）表，例如 DELETE u FROM users u JOIN orders o ON u.id = o.user_id —— 这里 u 就是被删的目标别名。
常见错误是漏掉目标表标识，或误写成 DELETE users, orders FROM ... 却没确认外键约束是否允许级联删除。这种写法会同时删两表，但若 orders 有子表（如 order_items），且未设 ON DELETE CASCADE，就会直接报错中断。
先用 SELECT 模拟再执行，否则容易全表误删
DELETE JOIN 的 WHERE 条件一旦写错，可能匹配出远超预期的行数。比如想删“30天前未支付的订单”，但忘了加 status = 'unpaid'，结果把所有历史订单都删了。
安全做法永远是：把 DELETE 替换成 SELECT COUNT(*) 或 SELECT id 跑一遍：
SELECT COUNT(*) FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.user_id IS NULL;
确认数量合理（比如几万条，不是几百万），再换成 DELETE u FROM ... 执行。别跳过这步——线上环境没有后悔键。
大范围关联删除必须分批 + 加休眠，否则锁表
即使用了 JOIN，只要一次删几十万行，InnoDB 仍会持锁很久，阻塞其他事务。尤其是 LEFT JOIN 清理孤儿数据时，扫描范围往往覆盖整张主表，极易触发锁升级。
解决方法不是放弃 JOIN，而是把它套进循环分批逻辑里：
- 用
LIMIT控制单次删除量（如LIMIT 5000） - 每次删完立刻
COMMIT，释放行锁和 undo 日志 - 加
SLEEP(0.3)降低 IO 压力，避免磁盘被打满 - 用
ROW_COUNT()判断是否还有数据可删，避免无限循环
示例存储过程关键片段：
WHILE ROW_COUNT() > 0 DO DELETE u FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.user_id IS NULL LIMIT 5000; COMMIT; SELECT SLEEP(0.3); END WHILE;
外键和索引缺失会让 DELETE JOIN 变慢十倍以上
如果 JOIN 条件字段没索引（比如 orders.user_id 无索引），MySQL 会走嵌套循环全表扫描，100 万用户 × 500 万订单 = 500 万亿次比较——实际就是卡死。
必须检查两点：
- 所有
ON字段、WHERE中的关联字段，都要有单独索引或联合索引前缀 - 若涉及外键，确认
foreign_key_checks是否开启；临时关闭虽能加速，但会跳过约束校验，仅限离线清理场景
一个常被忽略的坑：LEFT JOIN 删除孤儿记录时，orders.user_id 索引存在，但 users.id 若是自增主键就已足够；但如果 users 表用了 UUID 主键且没建额外索引，LEFT JOIN 性能会断崖下跌。
