一家做零售的企业，订单表三千多万行，查去年的报表要等三分钟，业务同事干脆不查了，凭感觉报数。老板问为什么系统这么慢，技术说数据太多，建议删一部分。老板不敢删，说万一以后要查呢，事情就僵在这儿。
该留的和该搬的分开
绝大多数查询只关心近三个月到近一年的数据，剩下的是备查。做法是按时间切分：热数据留在主库，保持在千万级以内；温数据放归档库，同库不同表或者不同实例；冷数据压缩后放对象存储或者磁带。分层之后，主库轻了，查询自然就快。
归档规则要先跟业务对
哪些数据可以迁走，不是技术自己定的。财务凭证的保存年限、合同和发票的留存要求、客户投诉记录要留多久，这些有法规和内部规定。把业务、财务、法务一起叫上，定一份归档策略：多久的数据迁走、迁到哪、谁有权限查。
归档后还要查得到
最容易失败的地方是归档之后业务查不了，等于白做。可行的方式是在系统里保留查询入口，命中老数据的请求转到归档库，用户感觉不到差别，只是慢一点。如果做不到透明，至少给财务和客服开一个单独的历史查询页面，别让他们干着急。
归档也要备份。很多人觉得归档库是冷数据，不重要，实际上它承载的是公司的历史账目。归档库的备份策略可以比主库松一些，但必须有，而且要做过恢复测试。真出了事，老数据丢了比新数据丢了更难补，因为根本没法重建。
太原的企业数据量普遍不算大，几百万到几千万行，多数不需要复杂的分布式方案。按时间分区加归档库，成本不高，效果明显。我的建议是趁系统还不算慢的时候做，等慢到影响业务了再动，压力大得多。归档我们建议按年切分，冷数据单独放，查询时按时间路由，主库就轻了。
数据归档的常见疑问
归档要多长时间
几千万行的场景，脚本跑一个通宵基本能完成，分批迁移避免锁表，别一次删太多。
归档数据要加密吗
涉及个人信息和财务数据的建议加密，至少控制访问权限并留审计日志。
能自动归档吗
可以，做成定时任务按策略执行，但要留监控和告警，避免某天任务异常把数据迁丢。
总结：老数据不是包袱，是资产，但要放对地方。热温冷分层、规则业务定、查询留入口、归档也备份，四件事做完主库才轻得下来。