活动系统最开始只有几万条订单，大家不会认真讨论“数据生命周期”。
后台想查就查，运营想导出就导出，日志临时塞数据库也没人觉得有问题。直到半年后，订单表越来越大，报表越来越慢，备份时间越来越长，连一次普通 DDL 都变得让人紧张。
海量数据的问题，往往不是突然爆炸，而是慢慢把系统磨钝。
它真正考验的不是“哪里能装下更多数据”，而是不同数据该不该继续待在同一个地方。
海量数据的问题，最开始通常不吓人。
第一年几十万行，查询很快；第二年几千万行，偶尔慢一点；到后面某个早上，运营要拉一份报表，页面转了半天，大家才突然意识到：这个表已经不是当年那个表了。
我见过一些系统，业务还没到真正爆发，数据先把维护成本撑起来了。备份变慢，迁移变慢，索引调整不敢随便动，连一个看起来普通的删除都要小心。
所以数据量不是一个数字问题，它会慢慢改变团队做每个操作时的心理负担。
查询、备份、归档、DDL、报表导出，每一件事都会被数据量放大。
一、单表变大后，很多操作都会变重
单表过大，最明显的是查询变慢。
但它影响的不只是查询。索引会变大，写入会受影响，更新和删除成本会上升，备份恢复时间变长，表结构变更也会更谨慎。
这时候不要只问“要不要分表”，先问几个更朴素的问题：
- 这张表里的数据是不是都一样重要？
- 最近订单和三年前订单访问频率一样吗？
- 查询是不是总围绕时间、用户、商户、状态？
- 报表查询是不是混在在线库里跑？
很多系统还没到必须分库分表的程度，先做冷热分离、归档和索引调整，就能解决大部分问题。
二、历史数据不能永远挤在在线库里
历史订单是很典型的数据。
它平时不怎么访问，但业务又要求查得到；它不常变，但一直占着在线表空间；它价值还在，但不该继续拖慢核心交易。
比较稳的做法是按业务规则归档。
比如最近 3 到 6 个月订单留在线库，历史订单迁移到历史表、归档库、对象存储或分析系统。
归档不是简单地复制和删除，它要考虑：
- 分批执行，避免影响线上。
- 可重试，失败后能继续。
- 可校验，迁移前后数量和关键字段一致。
- 可查询，用户需要历史记录时还能找到。
数据归档做得好，在线库会轻很多。
三、在线交易和报表分析不要互相折磨
在线业务库主要处理 OLTP，也就是高频、短事务、低延迟的增删改查。
报表分析更接近 OLAP，通常是大范围扫描、聚合、排序、统计。
把复杂报表直接压到在线库上，短期方便，长期危险。运营导出一个全年订单报表，可能把正常下单接口也拖慢。
更合理的方式是：
业务库
-> 同步或异步抽取
-> 数仓 / ClickHouse / Elasticsearch / 报表库
-> 报表和分析查询在线库负责业务正确性，分析系统负责查询效率。一个数据库不应该同时承担所有目标。
四、时序数据、文件和日志要各归其位
有些数据天生就不适合放在普通业务表里。
设备采集数据、监控指标、接口耗时，更像时序数据。它们写入频率高、按时间查询多、历史价值逐渐下降，适合时序数据库或专门的分区策略。
图片、附件、导出文件，也不应该直接塞进数据库。数据库保存元数据和地址，文件本体放对象存储或文件服务，通常更合理。
日志也是类似。业务日志、访问日志、错误日志、链路日志，如果全部进业务库，很快就会污染核心数据。日志应该服务于排查，而不是拖累交易。
五、数据生命周期要提前设计
很多系统的问题不是没有存储，而是没有生命周期。
一条数据从产生开始，可能会经历热数据、温数据、冷数据、归档数据，最后到过期删除。每个阶段访问频率不同，存储成本也不同。
如果一开始完全不设计生命周期，数据只会越堆越多。等数据库撑不住时再处理，迁移成本会很高，也更容易影响线上。
我更喜欢在设计阶段就把规则讲清楚：
- 最近多久的数据算热数据？
- 哪些数据需要长期保留？
- 哪些数据可以压缩或归档？
- 哪些数据到期必须删除？
- 历史查询的响应时间要求是多少？
这些问题不酷，但很现实。
六、可以带走的判断清单
- 表大不等于马上分表，先看冷热和访问路径。
- 历史数据要能查，但不一定要留在在线表。
- 报表分析不要长期压在线库。
- 时序数据、文件、日志要用适合它们的存储。
- 数据生命周期要提前定义，不要等撑不住再补。
海量数据存储的关键不是“装得下”，而是“放得对”。
本系列：
暂无评论