有个真相挺反直觉的：数据库性能崩塌，往往不是因为数据太多，而是因为冷热不分。

每个做过后端的工程师都经历过这个剧本。系统刚上线时，查询飞快，CPU悠闲，仪表盘秒开。订单表、日志表、消息表，数据往里灌，一切井井有条。你加了几个索引，性能回来了，以为问题解决了。

打开网易新闻 查看精彩图片

几个月后，新查询模式冒出来，索引越堆越多，旧的成了摆设。写入开始卡顿，备份拖到凌晨，CPU和内存曲线像心电图失控。这时候你去搜解决方案，得到的建议是：分库分表、水平扩展、给Kubernetes献祭一只山羊。

但真正的症结可能被忽略了——你的热数据里混着大量"幽灵"。

生产系统有个规律：活跃访问的几乎总是近期数据。三年前的webhook事件、五年前的订单详情，真的需要躺在主库里随时待命吗？不需要。但出于合规、财务、审计、法务，你又不能删。

解法很简单：把数据"冻"起来。

所谓冻结，不是删除，而是分层。近期数据保持可查询，旧数据迁移出去。表小了，索引小了，备份快了，IO压力降了。小数据库就是快数据库，这个道理朴素到让人忽视。

冷数据去哪？看场景。

同一数据库里建归档表，比如orders和orders_archive，适合偶尔需要访问、不想引入新系统的场景。数据仓库如BigQuery、Snowflake、ClickHouse、Redshift，面向BI和财务分析。甚至S3上的CSV、JSON文件，对日志和审计来说便宜、耐用、够用。

迁移策略要克制。写个定时任务，按TTL分批搬，别一次性全量操作——那是制造事故的标准姿势。小批量、渐进式、持续运行。

很多性能问题的解药，不是更复杂的架构，而是更清醒的数据分层意识。