【策划架构】字段冻结：历史数据的只读化归档设计

设计初衷

历史数据（超过 6 个月的旧赛季战绩、过期邮件、历史流水）与活跃数据混在同一存储里：查询越来越慢、误改历史的风险越来越高、备份体积无限膨胀。字段冻结把"过期的历史"转入只读归档库：冻结后的数据不可变更、只提供查询接口，活跃库只留 6 个月内的热数据——归档不是删除，是给历史盖上保险柜的盖子。

数值模型

冻结规则：末次变更时间超过 6 个月的数据行转入归档库（结构同源库，加冻结时间戳与归档批次号）；冻结后数据字段不可写，仅归档查询接口可读。生命周期：归档数据保留 2 年，到期按数据类型走销毁或转冷存储。查询路由：近期查询走活跃库，历史查询（战绩回溯、流水取证）走归档接口，接口层对玩家透明。体积与性能：归档迁移后活跃库体积降至 40%，热查询平均耗时从 380 毫秒降到 90 毫秒。豁免规则：涉及未结纠纷、司法调取的数据挂冻结豁免标记，豁免数据不迁移。数值验证：归档上线后误改历史数据类工单归零，活跃库备份时长从 40 分钟缩到 16 分钟。

配置示例

冻结参数单独一节。配置如下：

[FieldFreeze]
FreezeMonths = 6
ArchiveKeepYears = 2
QueryTransparent = 1
HotQueryMs = 90

豁免参数单独一节。配置如下：

[FreezeExempt]
DisputeHold = 1
JudicialHold = 1
ExemptTagField = hold_flag

扩展思路

变种方向：一是归档查询页，玩家可自助查询自己被归档的历史（旧赛季战绩页），归档对玩家有感知而不是黑洞；二是解冻流程，纠纷复核需要改归档数据时走解冻审批，解冻操作全程留痕；三是归档数据脱敏，归档前对手机号类敏感字段脱敏，历史库的泄露风险降级。设计纪律一条：冻结后的数据任何变更都要走"解冻审批加变更留痕"的完整流程——归档库一旦出现静默变更，只读承诺破产，归档的审计价值随之清零。