DELETE JOIN必须显式指定目标表别名，如DELETE u FROM users u JOIN orders o ON u.id = o.user_id；漏别名会报ERROR 1064，执行前须用SELECT验证影响行数，大范围删除需分批加休眠，ON和WHERE字段必须有索引。
DELETE JOIN必须显式指定目标表别名
MySQL 不允许写 DELETE FROM users JOIN orders，会直接报错 ERROR 1064 (42000)。你必须明确告诉它“删哪张表”，哪怕只删一张。语法核心是 DELETE t1 FROM table1 t1 JOIN table2 t2 ON ... —— 这里的 t1 就是唯一被删的目标表别名。
常见错误包括：
- 漏掉
FROM后的表别名，比如写成DELETE users FROM users JOIN ...（users是表名不是别名，不合法） - 误用逗号分隔多表：写成
DELETE users, orders FROM ...却没确认外键是否允许级联删除，结果在有子表（如order_items）时直接中断报错 - LEFT JOIN 场景下混淆逻辑：想删“无订单用户”，却写了
WHERE o.id IS NULL，但没给orders表起别名或 ON 条件字段没索引，导致全表扫描
执行前务必用SELECT验证匹配行数
把 DELETE 换成 SELECT COUNT(*) 或 SELECT id 是唯一靠谱的预检方式。例如清理“30天前未支付订单”，如果 WHERE 漏了 status = 'unpaid'，可能误删所有历史订单。
安全操作流程是：
- 先跑
SELECT COUNT(*) FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.status = 'inactive'; - 确认数量合理（比如预期几千条，不是几百万）
- 再执行
DELETE o FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.status = 'inactive'; - 如果涉及大范围删除（>10万行），跳过这步等于放弃回滚机会
大范围DELETE JOIN必须分批 + 加休眠
一次删几十万行，InnoDB 会长时间持有行锁甚至升级为表级锁，阻塞其他事务。尤其是 LEFT JOIN ... WHERE IS NULL 清理孤儿数据时，优化器常选择全表扫描主表，极易触发锁等待甚至死锁。
分批执行的关键点：
- 用
LIMIT控制单次删除量，例如DELETE o FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE u.id IS NULL LIMIT 5000; - 每次执行后加
SLEEP(0.1)（单位秒），缓解 I/O 和锁压力 - 在低峰期执行；避免与备份、统计任务争资源
- 不要依赖
ORDER BY配合LIMIT——JOIN 场景下排序代价高，且无法保证分片均匀
ON 和 WHERE 字段必须有索引，否则性能断崖式下跌
JOIN 的 ON 条件字段和 WHERE 中的过滤字段，如果没索引，MySQL 只能走嵌套循环（Nested Loop），复杂度接近 O(n×m)。一张百万级 orders 表关联十万级 customers 表，没索引时可能跑十几分钟还卡住。
检查方式很简单：
- 对
orders.customer_id和customers.id建联合索引或单独索引 - 用
EXPLAIN看执行计划：type列不能是ALL或index，理想是ref或eq_ref - 注意字符集一致性：如果
orders.customer_id是utf8mb4而customers.id是latin1，索引会失效
真正容易被忽略的是：LEFT JOIN 的 WHERE 条件里用 IS NULL 时，MySQL 无法利用右表索引做快速探查，必须依赖左表索引驱动+右表全扫描匹配——这时候右表字段有没有索引，影响反而不如左表驱动字段来得关键。
