北京
有个真相挺反直觉的：数据库性能崩塌，往往不是因为数据太多，而是因为冷热不分。
每个做过后端的工程师都经历过这个剧本。系统刚上线时，查询飞快，CPU悠闲，仪表盘秒开。订单表、日志表、消息表，数据往里灌，一切井井有条。你加了几个索引，性能回来了，以为问题解决了。
几个月后，新查询模式冒出来，索引越堆越多，旧的成了摆设。写入开始卡顿，备份拖到凌晨，CPU和内存曲线像心电图失控。这时候你去搜解决方案，得到的建议是：分库分表、水平扩展、给Kubernetes献祭一只山羊。
但真正的症结可能被忽略了——你的热数据里混着大量"幽灵"。
生产系统有个规律：活跃访问的几乎总是近期数据。三年前的webhook事件、五年前的订单详情，真的需要躺在主库里随时待命吗？不需要。但出于合规、财务、审计、法务，你又不能删。
解法很简单：把数据"冻"起来。
所谓冻结，不是删除，而是分层。近期数据保持可查询，旧数据迁移出去。表小了，索引小了，备份快了，IO压力降了。小数据库就是快数据库，这个道理朴素到让人忽视。
冷数据去哪？看场景。
同一数据库里建归档表，比如orders和orders_archive，适合偶尔需要访问、不想引入新系统的场景。数据仓库如BigQuery、Snowflake、ClickHouse、Redshift，面向BI和财务分析。甚至S3上的CSV、JSON文件，对日志和审计来说便宜、耐用、够用。
迁移策略要克制。写个定时任务，按TTL分批搬，别一次性全量操作——那是制造事故的标准姿势。小批量、渐进式、持续运行。
很多性能问题的解药，不是更复杂的架构，而是更清醒的数据分层意识。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
