核心表设计

数据是架构的底座

前面讨论的传输、存储、分发、安全，最后都要落到数据上。文件系统至少需要四类数据：

为什么不能塞进一张表

把「文件元数据」「上传任务」「分片」「审计」混在一张表里，会带来三个问题：

1. 生命周期不同：上传任务 24 小时就清理，元数据要长期保留，审计要防篡改。
2. 访问模式不同：元数据按 file_id 高频查询；分片按 upload_id 批量读写；审计是追加写入。
3. 扩展方向不同：任务表会膨胀收缩，审计表只增不减，混在一起互相拖累。

表之间的关系

file_metadata（文件长期事实）
  └── upload_task（上传过程，关联 file_id）
        └── upload_part（分片明细，N 行）

file_audit_log（旁路，记录所有文件操作）

• 文件状态流转以元数据为准（scanning → available → deleted）。
• 上传任务完成 / 过期后，任务与分片可清理，元数据保留。
• 审计记录独立于业务表，不可随意修改。

高敏字段的处理

• 文件 hash：用于去重与校验，保存即可。
• 敏感文件名 / 审核结论：按合规要求加密或脱敏。
• 审计日志：写入后只追加，防止篡改。

索引与容量

• 元数据按 file_id 主查，按 owner_id + created_at 支持列表查询。
• 分片表随任务一起清理，控制膨胀。
• 审计表用分区 / 冷热分层，防止无限增长。

一句话

四类数据各司其职：上传任务是临时过程，元数据是长期事实，审计是不可改的追踪记录。分开设计，系统才干净、可扩展。

下一节把一次完整上传走通一遍。

上一章节

控制面与数据面

下一章节

最终上传链路