备案站点的数据生命周期与归档清理

只增不删的数据，最后会变成运维负担

初期没人关心数据保留：反正磁盘便宜。两年后问题集中爆发——备份一次要跑一整夜、一条带时间范围的查询要走几十秒、账单里存储费用悄悄超过了计算费用。更麻烦的是，这时候再想删，已经没人敢确认哪些能删了。

关键要点

• 保留期要在表建起来的时候就定，而不是磁盘告警时才讨论。
• 合规有明确留存要求的数据（如访问日志）不能按成本随意删。
• 大表删除必须分批限速，一条语句删掉几百万行会锁表并拖垮主从。
• 删除之前先归档：删错可以恢复，直接硬删无法挽回。

先分类，再定保留期

数据类型	典型保留期	依据
访问日志	按合规要求	有明确留存义务，见 网站访问日志留存要求
业务单据	长期或按财务要求	业务与审计需要
用户行为埋点	3～12 个月	分析价值随时间衰减
应用运行日志	1～3 个月	排障为主，见 日志规范与集中检索
临时数据（验证码、会话、导出文件）	小时到天	用完即可清理
审计与操作留痕	长期	责任可追溯，见 运维权限治理与操作审计

制定保留期时要同时写清三件事：保留多久、到期后是删还是归档、谁来确认。缺了第三条，规则最后一定停在纸面上。

软删除与硬删除

软删除（打标记不真删）便于恢复和审计，但它不解决容量问题——数据还在表里，索引照样变大，查询还得额外加过滤条件，忘记加就会泄露已删除数据。

实用的组合是三段式：软删除（可恢复窗口，如 30 天）→ 归档到冷存储（保留期内）→ 硬删除。这样既有后悔药，又能真正释放在线库的容量。

大表删除：分批、限速、可中断

一条「删除两年前全部记录」的语句在千万行级别的表上是典型事故来源：长事务、锁等待、主从延迟飙升、回滚段暴涨。正确做法：

• 每批删几百到几千行，批与批之间留出间隔让复制追上。
• 任务要幂等、可中断、可续跑，写法见 定时任务运维：幂等、防重与补偿。
• 全程盯住主从延迟与连接数，延迟超阈值自动暂停，见 数据库运维与高可用。
• 按时间分区的表优先用「删除整个分区」的方式，代价远低于逐行删除。
• 删除后的空间回收本身也是重操作，需按在线变更流程安排，见 数据库变更与在线 DDL 实践。

归档：把冷数据挪出在线库

归档的目标是让在线库只保留热数据。常见去向：历史表、只读从库、对象存储（导出为压缩文件），存储类型与生命周期规则见 对象存储与静态资源托管。

归档必须验证两件事：归档文件能读回来，以及业务在归档后仍能满足查询需求（例如客服需要查两年前的订单）。归档前最好先确认有哪些查询会跨越归档边界，并给它们准备一条查询路径。

顺带解决的成本问题

数据瘦身对成本的影响是连锁的：在线库变小 → 备份更快更省 → 快照体积下降 → 恢复演练耗时缩短。所以数据治理通常是成本治理里性价比最高的一项，整体盘点方法见 服务器资源与成本治理；恢复能力的验证见 数据备份与容灾。

删除前必须确认的事

• 是否属于有法定留存期限的数据。
• 是否涉及个人信息，删除范围是否覆盖备份与下游副本。
• 是否有下游系统（报表、对账、风控）依赖这批数据。
• 删除动作本身是否留痕：谁执行、删了什么、什么时候。

常见坑

• 一条语句删几百万行：锁表、主从延迟、业务受阻。
• 只软删不归档：容量问题一点没解决。
• 忘记清理临时文件：导出文件、上传临时目录把磁盘塞满。
• 删除不留痕：事后查不清是谁删的。
• 只删主库不管备份与下游：数据依然散落在别处。

常见问题

保留期到底谁来定？

合规类数据按法规要求定，业务数据由业务方和技术方共同确认。技术侧单方面决定风险很大——你以为没人用的历史数据，可能正是财务对账的依据。

分批删除每批多大合适？

从小批量开始（如每批 500～1000 行），观察主从延迟与锁等待，再逐步调整。关键不是批量大小的绝对值，而是保证每批都是短事务，并在批间留出间隔。

删除之后磁盘空间为什么没释放？

多数数据库删除只是标记空间可复用，不会立刻归还操作系统。要真正回收需要重建表或整理表空间，属于重操作，需安排窗口并做好备份。

归档数据还需要备份吗？

需要。归档只是改变了存储位置和成本结构，数据价值和责任并没有消失，同样要有副本和恢复验证。

资料来源

主流数据库关于分区、批量删除与空间回收的官方文档，云厂商对象存储生命周期管理说明，以及个人信息保护相关公开法规要求。本文为通用运维说明，仅供参考，具体保留期限请以适用法规与业务要求为准。