不能直接写 DELETE ... JOIN 删除5张大表关联数据，因为MySQL 5.7+执行时极易锁表、超时及主从延迟飙升，根本原因是优化器无法有效索引下推，常退化为全表扫描+临时表构建，尤其任意关联字段未走索引时EXPLAIN显示type=ALL即宣告失败。
为什么不能直接写 DELETE ... JOIN 删除5张大表关联数据
MySQL 5.7+ 虽支持 DELETE t1 FROM t1 JOIN t2 ON ... JOIN t3 ... 语法，但生产环境执行时极大概率触发锁表、超时、主从延迟飙升。根本原因不是语法错，而是优化器无法对多表 JOIN 的 DELETE 做有效索引下推——它常退化为全表扫描 + 临时表构建，尤其当任意一张表没走索引（比如关联字段类型不一致、隐式转换）时，EXPLAIN 显示 type=ALL 就等于宣告失败。
常见错误现象：Lock wait timeout exceeded、从库 Seconds_Behind_Master 突增至数千秒、业务写入阻塞报警。
- 检查每张表的关联字段是否都有独立索引（不是联合索引里的第二列）
- 确认字段类型完全一致（
INTvsBIGINT、VARCHAR(50)vsVARCHAR(100)都会失效） - 用
EXPLAIN FORMAT=TREE（MySQL 8.0）或EXPLAIN ANALYZE（Percona）看实际执行路径，重点盯rows_examined
分步删除：先查ID再删，但必须加 LIMIT 和 ORDER BY
安全底线是「每次只删几千行」，避免单次事务过大。关键不是用子查询，而是控制主键范围——靠 WHERE id BETWEEN ? AND ? 比 WHERE id IN (SELECT ...) 快一个数量级，且能稳定利用主键索引。
示例场景：删掉 orders 表中状态为 'cancelled' 且关联的 users 已注销、products 已下架、payments 无成功记录、logs 无操作痕迹的订单：
SELECT o.id FROM orders o JOIN users u ON o.user_id = u.id AND u.status = 'inactive' JOIN products p ON o.product_id = p.id AND p.is_active = 0 LEFT JOIN payments pay ON o.id = pay.order_id AND pay.status = 'success' LEFT JOIN logs l ON o.id = l.order_id WHERE o.status = 'cancelled' AND pay.id IS NULL AND l.id IS NULL ORDER BY o.id LIMIT 5000;
拿到这 5000 个 id 后，再执行：
DELETE FROM orders WHERE id IN (1001,1002,...,5000);
- 务必加
ORDER BY id，否则LIMIT结果不可控，可能漏删或重复删 -
IN列表长度别超 1000（MySQL 默认max_allowed_packet限制），拆成多个批次 - 在从库上先
SET sql_log_bin=0测试语句执行时间，确认rows_affected符合预期
用 pt-archiver 替代手写脚本，但得关掉 --no-delete
Percona Toolkit 的 pt-archiver 是专为大表归档/删除设计的工具，它自动分批、限速、监控延迟，比手写循环更可靠。默认行为是「把数据导出后删源表」，但你要的是纯删除，所以必须显式禁用导出：
pt-archiver \ --source h=prod-db,D=shop,t=orders \ --where "status='cancelled'" \ --limit 1000 \ --txn-size 1000 \ --sleep 0.1 \ --no-delete \ --progress 1000 \ --statistics
上面命令其实只是模拟——真正执行要删掉 --no-delete 参数，并补上关联条件（用 --where 拼接所有 JOIN 条件，或提前建好物化中间表）：
--where "id IN (SELECT o.id FROM orders o JOIN users u ON ... WHERE u.status='inactive' AND ...)"
-
--limit和--txn-size必须设为相同值，避免事务跨批次 -
--sleep值根据主从延迟动态调：延迟 > 1s 时至少设 0.5 - 首次运行加
--dry-run，它会打印将要执行的 DELETE 语句，可人工验证
删完之后必须立刻检查 information_schema.INNODB_METRICS
很多人删完就以为结束，但 InnoDB 的 MVCC 机制会让已删数据的 undo log 保留一段时间，持续占用空间并拖慢 purge 线程。生产库上必须确认 purge 是否跟得上：
SELECT NAME, COUNT FROM information_schema.INNODB_METRICS
WHERE NAME IN ('dml_deletes', 'purge_undo_log_pages', 'purge_undo_log_bytes');
如果 dml_deletes 数值远大于后两者，说明 purge 堵塞——此时 SHOW ENGINE INNODB STATUS 里会看到 PURGE DONE FOR TRX 进度停滞。
- 立即检查
innodb_purge_threads是否为 1（MySQL 5.6 默认值，建议调到 4） - 观察
innodb_max_purge_lag是否被触发（会导致 INSERT/UPDATE 延迟，但 DELETE 不受影响） - 最危险的是删完立刻做
OPTIMIZE TABLE——这会锁表重写，必须避开业务高峰
真正麻烦的从来不是怎么删，而是删的过程中如何不让主从延迟雪崩、不卡住其他业务事务、以及删完后 undo log 不堆积。这些点漏掉任何一个，都可能让一次计划内操作变成线上事故。
