登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  数据库 >  MySQL

MySQL 分区表删除历史分区为什么比 DELETE 更快

来源:17golang原创

时间:2026-09-09 02:30:59 461浏览 收藏

MySQL 分区表删除历史分区通常比对整张表执行 DELETE 更快,关键不在于 SQL 写法更短,而在于两者的工作粒度不同:DELETE 要逐行判断条件、维护索引并产生行级变更记录;ALTER TABLE ... DROP PARTITION 直接移除一个已经按范围隔离的数据边界。代价也很明确:目标分区里的数据会整体删除,不能把它当成可回滚的“快速 DELETE”。

要点速览
  • 先核对分区键和边界,再决定要删的分区名。
  • DROP PARTITION 适合整段过期数据,DELETE 适合分区内只删一部分。
  • 删除后要检查分区定义、未来写入范围和备份/归档策略。

先确认分区边界,再谈清理速度

以按月保存订单事件的表为例,真正需要确认的不是“历史数据有多少行”,而是目标月份是否完整落在某个分区里。MySQL 8.4 的分区信息可从 INFORMATION_SCHEMA.PARTITIONS 查看,表结构则用 SHOW CREATE TABLE 复核。下面的查询只读元数据,不会修改表。

-- 先看分区名、范围描述和估算行数
SELECT PARTITION_NAME, PARTITION_DESCRIPTION, TABLE_ROWS
FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'order_events'
ORDER BY PARTITION_ORDINAL_POSITION;

-- 再确认分区表达式、MAXVALUE 和存储引擎
SHOW CREATE TABLE order_events;

如果表按 RANGE COLUMNS(created_at) 划分,p202501 可能代表一段明确的半开区间;如果使用 RANGE(YEAR(created_at)),边界的含义又不同。不能只凭分区名猜日期,更不能直接删除 pmax。先用一条带边界条件的查询抽样核对最早、最晚记录,再执行 DDL。

MySQL 时间范围分区表中逻辑表、created_at 分区键、历史分区与保留边界的技术关系图
图1:时间分区把历史数据放进独立边界,清理动作首先要核对这个边界。

为什么 DROP PARTITION 通常比逐行 DELETE 快

DELETE FROM order_events WHERE created_at 仍然是一组行级操作:服务器需要找到满足条件的记录,更新聚簇索引和二级索引,写入 Undo/Redo,并等待后续清理。这种方式能精确保留分区里的新数据,但数据量越大,逐行工作越重。

ALTER TABLE order_events DROP PARTITION p202501 的前提是:p202501 本身就是完整的保留单元。MySQL 官方文档明确说明,删除 RANGE 或 LIST 分区时,该分区存放的数据也会被删除;在支持原生分区的路径下,它可以按分区边界处理,而不是扫描每一行。因此,历史数据恰好按分区切齐时,清理成本通常更稳定。

“更快”不是固定倍数,也不是所有场景都成立。分区很小、只需删除少量行、或者任务还要保留分区定义时,DELETETRUNCATE PARTITION 可能更合适。更重要的是,DROP PARTITION 是数据删除动作:误选一个分区,影响范围就是这个分区的全部记录。

MySQL 逐行 DELETE 与 DROP PARTITION 在条件匹配、索引日志和整分区边界上的静态对比关系图
图2:两种清理方式的工作粒度不同,整分区删除省掉了逐行匹配和索引维护,但代价是边界内数据整体消失。

执行 DROP PARTITION 前后要核对什么

确认目标分区只含过期数据后,再执行一次分区级 DDL。示例中的注释说明了危险边界,生产环境不要把未经审阅的分区名直接拼到自动化脚本里。

-- 只删除已经完成保留期的整个月份
ALTER TABLE order_events
  DROP PARTITION p202501;

-- 删除后重新查看分区定义,确认下一个写入范围仍然存在
SHOW CREATE TABLE order_events;

-- 需要时检查目标月份已没有记录
SELECT COUNT(*) AS remaining_rows
FROM order_events
WHERE created_at >= '2025-01-01'
  AND created_at 
场景更合适的动作关键风险
整个历史月份都过期DROP PARTITION分区内数据与分区定义一起消失
清空分区但以后还要继续使用TRUNCATE PARTITION仍需确认语句影响范围
分区内只过期一部分DELETE可能产生较多行级日志和锁等待
要调整边界但保留数据REORGANIZE PARTITION新旧范围必须完整覆盖且不能重叠

权限、备份和并发也要列入发布清单。官方手册指出,执行 ALTER TABLE ... DROP PARTITION 需要表的 DROP 权限;如果归档要求是“先保存后删除”,应在 DDL 前完成可恢复的归档,而不是把数据库回收当成备份。

让定期清理不破坏下一次写入

按时间分区的清理任务通常与“提前创建未来分区”成对出现。删除旧分区后,检查高端分区或 MAXVALUE 的设计:新增范围只能落入已有合法边界,不能因为清理脚本误删了兜底分区而让新数据插入失败。对 RANGE 分区,边界必须递增;需要改变范围但不丢数据时,使用 REORGANIZE PARTITION,不要用 DROP PARTITION 代替迁移。

可以把每次任务的核对结果记录成三项:删除前的分区定义、实际执行的分区名、删除后的剩余范围。这样即使清理由定时任务触发,也能快速回答“删了哪段数据、下一段数据会写入哪里、是否还需要补建分区”。

常见问题

DROP PARTITION 会只删除满足日期条件的行吗?

不会。它删除指定分区中的全部数据,所以必须保证分区边界已经与保留策略对齐。

只想清空数据但保留分区名怎么办?

优先评估 ALTER TABLE ... TRUNCATE PARTITION,它的语义是清空选定分区而保留分区结构;仍要先确认备份和并发影响。

分区表用了 DELETE 就一定慢吗?

不一定。小批量、非整段数据或需要精确条件时,DELETE 更合适;“更快”的优势来自一次移除完整分区,而不是分区表会自动优化所有删除。

资料:MySQL 8.4 RANGE/LIST 分区管理MySQL 8.4 分区管理

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>