MySQL 分区表清理历史数据为何越删越慢：DROP PARTITION 的锁与回收边界

线上订单历史表按月分区后，清理上一季度数据的耗时从几分钟涨到了半小时，业务侧还出现了偶发的锁等待。问题通常不是“分区没生效”，而是把整段历史数据当成普通行集合执行了逐行 DELETE。如果数据边界和保留策略已经按分区设计，删除整个时间片更适合使用 DROP PARTITION，但执行前必须确认分区范围、备份要求和未来分区是否能自动补齐。

慢删除现场：SQL 只写了一句 DELETE

假设表名为 order_event，按 created_at 做月度 RANGE 分区。值班脚本最初这样清理：

DELETE FROM order_event
WHERE created_at 

监控里可以看到三个典型信号：事务持续时间变长，undo 空间占用持续上涨，其他写入请求偶尔出现等待。这个语句即便能触发分区裁剪，也仍然要逐行处理匹配记录、维护二级索引并等待事务提交完成；分区裁剪只是减少了扫描范围，不会把行级删除直接变成轻量的元数据操作。

先看分区边界，再判断能不能整片丢弃

第一步不要急着改SQL，先确认分区名、上界值和估算行数：

SELECT PARTITION_NAME, PARTITION_METHOD,
       PARTITION_DESCRIPTION, TABLE_ROWS
FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'order_event'
ORDER BY PARTITION_ORDINAL_POSITION;

如果结果中 p202604 的范围恰好覆盖 2026 年 4 月，并且保留规则允许整月删除，就可以把操作目标从“批量匹配删除大量行”转换为“直接移除一个已命名分区”。如果分区是按日或按周切分的，也要逐个核对范围，不能只凭分区名的命名规则猜测实际边界。

再用下面的语句确认优化器是否只会扫描目标分区；这里只做读取检查，不要在业务高峰期直接执行改表操作：

EXPLAIN SELECT COUNT(*)
FROM order_event
WHERE created_at >= '2026-04-01'
  AND created_at 

输出中的 partitions 应尽量只包含 p202604。如果扫描范围覆盖了全部分区，先检查条件是否对分区列做了函数转换，或者边界类型是否与分区表达式的定义一致。

DROP PARTITION 的正确用法与不可逆提醒

确认数据已经归档、备份要求已经满足后，可以执行对应操作：

ALTER TABLE order_event
DROP PARTITION p202604;

这个操作不是把行移到回收站，而是让目标分区及其中的所有数据直接消失。执行前至少完成三件事：

1. 把实际执行的SQL、操作者和审批单号写入内部变更记录。
2. 确认应用侧的查询逻辑不会依赖已删除月份的数据，也确认外部报表已经完成对应时间段的取数。
3. 确认下一个月份的分区已经提前建好；必要时提前 ADD PARTITION，避免新数据落入 MAXVALUE 分区后失去后续的滚动清理策略。

如果只是删除某个月份中的少量异常行，不能为了省事直接丢弃整个分区。此时应按主键范围分批删除，每批提交后观察锁等待和主从复制延迟；分区只是缩小了候选数据的范围，并没有改变逐行删除本身的事务成本。

执行后怎么确认没有留下隐患

完成变更后重新查询分区清单，确认 p202604 已经消失且剩余的未来分区仍然连续。再抽查数据保留边界：

SELECT MIN(created_at), MAX(created_at), COUNT(*)
FROM order_event
WHERE created_at 

最后检查数据库连接状态、锁等待指标、复制延迟和磁盘使用率。不要只看SQL返回成功就结束操作；如果应用有缓存或离线数仓，还要确认下游任务不会继续读取被清理的月份数据。如果发现当前的分区边界设计无法支撑后续的滚动清理，应先调整分区方案，再补上自动建分区和执行失败的告警机制。

常见问题

DROP PARTITION 会比 DELETE 更快吗？

整分区淘汰通常比逐行删除更适合历史数据清理，但实际耗时仍受表结构、存储引擎、并发负载和磁盘回收机制影响。不要把“快”理解为完全没有锁或者没有任何变更风险。

DELETE 也能使用分区裁剪，为什么还会慢？

裁剪只是不访问无关分区，匹配到的行仍要逐条删除、维护索引并写入事务日志。目标数据量很大时，扫描范围变小并不能消除事务本身的开销成本。

误删分区后能用 ROLLBACK 恢复吗？

不能把它当作普通事务操作依赖回滚恢复。应在变更前完成可恢复的备份或归档，并把对应恢复演练纳入高风险操作的前置检查清单。

总结

分区表的价值不只是让查询少扫描无关数据块，也包括让历史数据按完整时间片直接退场。遇到清理变慢时，先从分区元数据确认边界，再在归档和恢复条件都明确的前提下选择 DROP PARTITION；对于分区内的局部删除，仍按小批次、可观察、可随时停止的方式处理。