TG咨询应用数据不必全部放在同一类存储中。规划移动应用运行数据的冷热分层存储时，先看数据多久会被读取、读取延迟要求多高，以及丢失或恢复失败会造成什么影响。分层不是单纯按创建时间搬数据，而是把常用数据留在快速访问层，把低频但仍需保留的数据放到成本和性能更合适的层。
先按访问方式划分，而非只看年龄
热数据通常需要低延迟读写，例如当前登录会话、最近的订单状态、尚未完成的任务记录。温数据访问较少，但仍可能被用户或运营流程调取，例如近几个月的历史记录。冷数据很少读取，可能因审计、争议处理或用户查询而需要长期保留，例如已结束流程的附件和较早的操作日志。
“热、温、冷”没有通用的天数边界。可先用近7至30天作为热数据观察窗口、30至180天作为温数据候选范围，再依据真实访问日志调整；这些只是试运行起点，不适用于所有产品。移动端启动时必读的数据，即使很旧，也不应仅按年龄直接归档。
让数据形态匹配存储层
热层：支撑在线读写
结构化且需要查询、更新的数据，可放在关系型数据库中，并围绕常见查询建立索引。Redis一类内存数据存储适合缓存可重建的数据或短期状态，但不宜把唯一副本只留在缓存里。缓存过期后能否从数据库恢复，应作为设计条件。
温层：保留可查询能力
温数据可以继续放在数据库的历史表或分区中，也可以将附件、图片等大文件放入对象存储，数据库仅保留对象标识、归属用户、创建时间和访问权限等元数据。数据库分区便于按时间管理记录；对象存储更适合大量非结构化文件，但具体访问延迟、费用和检索方式取决于服务配置。
冷层：降低低频数据的在线成本
归档存储适用于很少读取、可以接受较慢恢复的数据。若用户仍要求即时打开历史内容，就不能只因为访问量低而选用取回较慢的层。归档前还要确认文件格式、加密密钥和索引信息能够长期使用；冷存储降低在线访问成本，不等于可以忽略备份和恢复。
用可回滚流程实施迁移
- 盘点数据：按数据类型记录体量、最近访问时间、读写频率、保留要求和关联功能。把可重建缓存与不可替代的用户记录分开。
- 设定规则：为每类数据确定热、温、冷的进入条件，以及删除期限。法规、合同或用户删除请求有要求时，优先遵守相应要求，不把“归档”误当作“永久保留”。
- 先复制再核验：迁移时保留稳定的记录标识，先写入目标层，再比对记录数、文件大小或校验和，并抽样读取。避免先删源数据再验证目标副本。
- 切换访问路径：应用通过统一的数据访问接口读取内容；遇到归档对象时，明确显示正在恢复或不可即时读取等状态，避免客户端无限重试。
- 观察并回滚：监测读取延迟、迁移失败率、恢复耗时和存储费用。发现权限丢失、数据不一致或关键请求变慢时，暂停迁移并切回原数据源。
用指标检验分层是否有效
移动应用运行数据的冷热分层存储规划，应同时看成本和用户体验：热层的关键接口延迟是否达标，历史数据访问是否增加等待，归档恢复是否经过实际演练，以及重复副本和过期数据是否按策略处理。可以先对一种非关键数据做小范围试运行，再扩展到其他类型；没有读写统计时，先采集一段时间的访问日志，而不是凭经验一次性搬迁。
常见问题
数据多久没访问就算冷数据？
没有固定标准。结合访问日志、业务恢复要求和存储服务的取回时间确定，并定期复核。
冷数据可以直接删除在线数据库记录吗？
只有确认归档副本可读、索引可定位、保留要求允许后才考虑清理；建议先复制、校验，再按批次删除。
用户查看历史记录时怎么办？
若数据位于较慢的归档层，应设计明确的恢复流程和等待提示。对必须即时响应的内容，应保留在线副本或选用更快的存储层。
冷热分层能替代备份吗？
不能。分层解决访问与成本匹配，备份用于应对误删、故障等情况，两者需要分别制定和验证。
归根结底，移动应用运行数据的冷热分层存储规划要从访问行为和恢复要求出发，再选择存储层、迁移规则与保留期限；先小范围验证，通常比一次性调整全部数据更稳妥。