数据模型与 Schema 演进：从表设计到线上平滑迁移

用户域：user(id, username, password_hash, profile, created_at, deleted_at)
内容域：post(id, author_id, content, media_json, status, visibility,
              created_at, updated_at)
社交域：follow(id, follower_id, followee_id, created_at)
        interaction(id, user_id, target_type, target_id, action, created_at)
时间线域：timeline_cache(user_id, author_id, post_id, scored_at)

设计原则：
□ 单条内容一行：post 不存数组/嵌套，便于检索与统计
□ 关注关系唯一：(follower_id, followee_id) 唯一索引，防重复关注
□ 互动落明细 + 计数冗余：明细表 + 计数列（见第 7 节）
□ 时间戳统一：created_at 用 UTC 存储，展示时转本地时区

热层（Redis/内存）：
  timeline:user:{uid}  ZSET  ← 最近 N 条，scored by 时间
  → 秒级拉取，命中率 >95%

温层（PostgreSQL 分区表）：
  post 表按月/按 id 分区，覆盖「最近几月」的翻页回溯
  → 按月分区 + 分区键裁剪，翻页只扫对应分区

冷层（归档存储/S3/冷库）：
  超过 N 个月的内容进归档表/对象存储，保留元数据索引
  → 按 created_at 归档，索引行仍留在在线库

写入路径：
写 post 表（温层） → 同步写 Redis 时间线（热层） → 后台归档
读取路径：
先查热层 → 命中即返回 → 未命中翻温层分区 → 更早走冷层索引

核心查询与索引：
□ 单用户内容列表：post(user_id, created_at) 复合索引
□ 关注列表：follow(follower_id, created_at)
□ 粉丝列表：follow(followee_id, created_at)
□ 互动明细：interaction(target_type, target_id, created_at)
□ 热搜/统计：按时间窗口聚合（列存或物化，见统计篇）

读写分流：
□ 读走从库/缓存，写走主库
□ 时间线读（高 QPS）→ 缓存优先，DB 兜底
□ 互动计数读 → 计数器缓存 + 异步落库

索引陷阱：
✗ 每加一个查询就加一个索引 → 写放大爆炸
✓ 先量化查询频率（哪些是真热查询），再决定索引
✗ 低基数列单独建索引（如 status 枚举）
✓ 复合索引按「等值列在前、范围列在后」排列

软删除 vs 硬删除：
□ 硬删除：物理 DELETE，不可恢复，级联难控
□ 软删除：deleted_at 置值，逻辑上不可见，数据仍可审计/恢复

墓碑（Tombstone）：
□ 时间线/缓存里的已删内容：写一条「墓碑」占位
□ 作用：防止残留的互动/转发仍能打开内容
□ 处理：读取时墓碑过滤；定期清理墓碑记录

账号注销的连锁：
注销 user → 软删其内容（保留评论上下文） → 墓碑覆盖时间线
  → 粉丝/关注关系软删 → 计数扣减异步执行
  → 内容保留「已注销用户」占位而非直接消失

三件套：
1. additive（加列）：新字段可空 / 带默认值，直接 ALTER
   → 旧行无值，读到默认 → 不阻塞读写
2. backfill（回填）：新字段的存量数据分批补值
   → 小批量轮询主键范围，限速，可暂停
3. 双写（dual write）：新旧结构同时写，灰度切换读
   → 新列写满后，读切新、写停旧，最后清旧列

失败安全：
□ 每步可回滚：加列可回滚、backfill 可暂停、双写可切回
□ 先小流量验证 backfill 正确性，再全量

-- additive：先加可空列
ALTER TABLE post ADD COLUMN is_pinned Boolean DEFAULT false;
-- 再 backfill 存量（分批，每次 5000 行）
UPDATE post SET is_pinned = false WHERE is_pinned IS NULL AND id < ?;
-- 双写期：新旧写入都带 is_pinned，读侧灰度切换

拆分手段（按需组合）：
□ 时间分区：按月 RANGE 分区，老分区可 DETACH 归档
□ 垂直拆分：把大字段（正文/媒体 JSON）拆到附属表，主表瘦身
□ 冷热归档：超过 N 个月的内容搬到归档表/对象存储
□ id 分段：历史 id 段与近期 id 段分库（较少用，迁移成本高）

归档流程：
热库 → 定时任务扫描 created_at 边界 → 复制到归档存储
  → 在线库软删/分区脱机 → 保留小索引（post_id → 归档位置）

生命周期约定：
□ 定义「内容可离线」的条件（如超过 6 个月、访问频率低）
□ 归档行提供「点击再加载」体验，而非直接 404
□ 归档成本远低于在线存储，是长期运营的必选项

三种计数模型：
□ 实时精确：每次互动实时更新计数列 → 写放大、热点行争锁
□ 异步计数：互动写明细，后台聚合写计数 → 秒级延迟、最终一致
□ 快照+增量：每日快照 + 增量日志 → 用于日报/榜单，非实时

热点问题：
□ 大 V 的粉丝数/点赞数是热点 key → 分片计数（多个计数桶合并）
□ 计数与明细不一致 → 周期性对账任务，以明细为准重建计数

对账机制：
对账任务：扫描明细表 → 按目标聚合 → 与计数列比对 → 差异修复
触发：每日一次全量对账 + 发现异常时的定点对账

工具链选型：
□ Flyway / Liquibase（JVM 生态，版本化 SQL 迁移）
□ golang-migrate / goose（Go 生态）
□ 自定义迁移 runner：批量 backfill + 双写切换脚本

流程：
1. 迁移脚本进版本库，命名带顺序（V2_xxx.sql）
2. CI 在临时库执行全量迁移，校验成功
3. 发布时按批执行：additive → backfill → 双写
4. 灰度：先 1% 流量切新结构，观察错误率/延迟
5. 全量 + 收尾：切新、停旧、清理临时列

回滚预案：
□ 每步迁移前记录 undo 语句（DROP COLUMN / 恢复默认值）
□ 双写期间任何异常 → 读切回旧结构，写保持双写
□ 迁移任务本身幂等：重复执行不产生副作用

阶段 1（MVP）：单 post 表 + follow + interaction，无缓存
  → 千级 DAU 够用，但时间线查询已经开始慢

阶段 2（增长期）：引入 Redis 时间线热层 + 按月分区
  → 命中率 95%+，时间线查询降为微秒级

阶段 3（算法期）：post 加 is_pinned/score 列（additive）
  → 个性化 Feed 需要分数，backfill 历史数据

阶段 4（治理期）：内容软删 + 墓碑 + 审核状态列
  → 举报下架、注销合规成为硬需求

阶段 5（成本期）：老内容归档到对象存储
  → 在线库瘦身，查询延迟稳定

每步的取舍：
□ 阶段 2 的代价：缓存一致性要处理（缓存失效策略）
□ 阶段 3 的代价：backfill 大规模执行的时间与资源
□ 阶段 5 的代价：归档内容「点击再加载」体验