2、历史数据清理概述：清理与归档的定义、清理的触发条件、业务价值与成本考量
聊历史数据清理之前，我想先解决一个常见的认识误区。很多人觉得「清理」就是把没用的数据删掉，「归档」就是把不用的数据搬走。嗯，这么说对了一半。但我可以告诉你，在实际项目里，这两个动作往往搅在一起，分不清的话后面会踩很多坑。
2.1 清理与归档：不是一回事，但最好一起做
先给个简单的定义：
- 数据清理 —— 从存储系统中彻底移除那些已过生命周期、不再有业务价值的数据。删除后不可恢复，空间直接释放。
- 数据归档 —— 将历史数据从高性能在线存储迁移到低成本冷存储中，保留查询能力但降低存储费用。数据仍然存在，只是「睡着了」。
我记得刚带团队做第一个治理项目时，产品经理说「把三年前的数据清掉」。结果开发同学直接 DELETE FROM order_log WHERE create_time < '2020-01-01'。一周后财务要拉历史报表，发现订单表里少了一大半数据，差点出生产事故。那次之后，我定了一条铁律：清理之前必须先确认有没有归档需求。
| 对比维度 | 数据清理 | 数据归档 |
|---|---|---|
| 最终目标 | 释放存储 + 提升访问性能 | 降低存储成本 + 保留回溯能力 |
| 数据是否可查 | 否，彻底删除 | 是，但需要额外等待或走冷查询 |
| 存储介质 | 无 | 廉价硬盘 / 对象存储 / 磁带 |
| 合规风险 | 高（需确认法律法规保留期） | 低（数据仍然可控） |
| 业务侧感知 | 不可逆 | 可恢复，但延迟变高 |
实际项目中，我习惯把这两个动作组合成一个流程：先归档，再清理。这样既满足了成本优化，又能兜底业务突然翻旧账的请求。
2.2 什么时候该做清理？五个触发条件
并不是所有表都值得做历史清理。我见过一些团队每季度对所有表跑一次 purge，结果业务频繁报错，因为很多「历史数据」其实是业务刚需。到底什么时候该触发？我总结了几块硬性指标：
- 存储水位告警 —— 磁盘使用率超过 85%，或者数据库文件大小接近实例规格上限。说白了就是「快满了，必须腾空间」。
- 性能瓶颈 —— 全表扫描耗时指数级上升，或者重要查询因为扫描了大量历史数据而超时。我在一个电商项目里遇到过，订单表 2TB，其中 1.6TB 是超过 2 年的数据，每次跑月报要等 40 分钟。清理后直接降到 3 分钟。
- 法律法规到期 —— 比如金融行业要求交易记录保留 5 年，超过 5 年的数据可以清理，但不能提前。我个人建议把保留策略写到元数据里，用定时任务自动判断。
- 数据生命周期策略到期 —— 业务上定义好的生命周期，比如日志数据只保留 90 天，90 天后自动进入冷归档或清理环节。这需要产品经理和 DBA 提前对齐。
- 合规审计要求 —— 个别敏感数据（比如用户身份证号、支付卡号）在达到保留期后，需要做脱敏或彻底清除。这个通常不能等系统自动触发，监控告警到了就要人工介入。
--retention_days=90 --force_archive=true --delete_after_archive=true。这样每次执行都有记录，出了问题可以回溯。
2.3 业务价值：不只是省硬盘钱
很多老板觉得历史数据清理就是「省存储费」。嗯，存储费确实是大头，但真实价值远不止这些。我列三个你可能没想到的点：
- 提升在线查询响应速度 —— 数据量降下来之后，索引更小、B+树层次更低、扫描更快。特别是 NoSQL 数据库，C* 和 MongoDB 的分片中数据分布更均匀，读延迟能降低 50%-80%。
- 降低备份和恢复时间 —— 全量备份时长直接和历史数据量正相关。清理后，备份窗口可以从 8 小时缩到 2 小时，而且恢复 RTO 也能从小时级降到分钟级。
- 减少运维人力投入 —— 数据量少了，慢查询调优、索引重建、分区维护的频率都会下降。说白了就是 DBA 不用天天半夜处理磁盘满告警了。
我记得有一次帮一家客户做系统优化，他们每天凌晨跑一次全量备份要 6 个小时，经常影响白天业务。我们清理了大约 30% 的僵尸数据之后，备份时间直接降到 1.5 小时。运维团队终于不用再提心吊胆地看备份窗口了。
2.4 成本考量：清理不是免费的
说了这么多好处，我必须提醒你一个问题：清理本身是要花钱的。
你想想看，扫描大量历史数据、做校验、做删除、再做索引重建，这些操作会消耗 CPU、内存、IOPS，如果赶上业务高峰期跑清理，很可能把数据库打崩。我以前就吃过这个亏：在一个 OLTP 库上直接跑 DELETE ... WHERE 大范围删除，结果事务日志撑爆了磁盘，整个库挂了 20 分钟。
正确做法是分步走：
- 估算清理成本 —— 先评估要清理的数据量、需要的时长、对 IO 的影响。小数据量（少于 100GB）可以直接在业务低峰跑；大数据量（TB 级）必须拆成小批次，结合归档和清理流程做。
- 计算存储节省 vs 清理开销 —— 比如清理 1TB 数据能省 2000 元/月的存储费，但清理本身需要 2 小时耗用高 IO，可能导致其它查询变慢甚至加一段免运维协调时间。算清楚这笔账再动手。
- 评估业务影响 —— 有些历史数据被其它下游系统引用，清理前必须通知所有下游，确认没有引用链。不然业务方突然发现数据对不上了，锅就到你头上了。
我一般建议在项目初期就做一个成本-收益表格，列清楚每个表的清理收益和潜在风险。这样跟老板汇报的时候，一句「投入 1 元成本可以省 10 元存储费」，决策就快多了。
--dry-run 模式，先统计可清理的记录数、预估空间节省，输出报告。确认无误后再切到真正的执行模式。这个习惯帮我避免了好几次误删。
2.5 一张图串联核心逻辑
下面这张图把清理 vs 归档的触发条件、业务价值、成本考量串了起来。我画的时候故意把「业务验证」和「合规检查」放在了最前面——嗯，这两步做不好，后面全是白干。
2.6 小结一下
这一章我们把清理和归档的定义讲清楚了，也列出了五个常见的触发条件。业务价值上，除了省钱，更重要的是优化性能、减轻运维负担。成本考量这块，我特别想强调一句：不要为了省一百块的存储，花一万块的故障恢复成本。动手之前，一定先算清账，做好风险预案。