主键策略
全库统一使用 BIGINT 雪花 ID。相比自增 ID，雪花 ID 趋势递增（保证 B+ 树写入性能）且可在分布式环境下本地生成，无需中心化发号。对外暴露时用 hashid 混淆，避免被枚举。
Database Schema
数据表设计
全部表按八个业务域组织，采用 MySQL 8.4 语法（InnoDB + utf8mb4_0900_ai_ci + datetime(3) + 原生 JSON）。每张表给出字段类型、约束、索引与设计说明，并对关键取舍（冗余、软删除、JSON 边界、物化路径、菜单树结构）逐条解释。这些约定在写第一张表时就应统一，事后调整的代价极高。
- 数据表
- 53 张
- 字段总数
- 433 个
- 业务域
- 8 个
- 设计约定
- 8 条
实体关系全貌
按业务域分列展示 24 张核心表及其外键关联。悬停任一实体可高亮其全部关联边，并显示关系基数。
核心实体关系图（ER）
悬停任一实体，高亮其全部关联八条全局设计约定
这些约定适用于所有表，是数据层保持一致性的基础。
时间字段
全部使用 datetime(3)（毫秒精度），统一以 UTC 存储，展示时按 Asia/Shanghai 转换。每张表必备 created_at / updated_at，updated_at 用 ON UPDATE CURRENT_TIMESTAMP(3) 自动维护。
软删除
deleted_at 为 NULL 表示未删除。社区类产品必须软删除，因为删除帖子会破坏评论上下文。物理清理由定时任务在冷静期后执行。
计数冗余
member_count、comment_count、score 等计数一律冗余存储 + Redis 增量维护，禁止在列表查询中做实时 COUNT(*)。冗余值由定时任务校正。
JSON 的边界
只用于「整体读写、不参与过滤排序」的小集合，如 user_settings.notify_prefs、outbox_events.payload、pages.toc。凡需要按内部字段查询的，一律拆列或拆表 —— MySQL 的 JSON 函数索引可用但代价不低，不要滥用在核心查询路径上。
索引原则
每个列表查询都应有对应的复合索引，且遵循最左前缀。索引顺序按「等值条件 → 范围条件 → 排序字段」排列。写入密集的 votes 表需控制索引数量。
位掩码权限
community_moderators.permissions 用整型位掩码存储（1=删帖 2=封禁 4=加精…），判定时按位与运算，避免为每种权限建列或建关联表。
物化路径
comments.path 与 community_menu_items.path 存储形如 /1024/2048/ 的祖先路径，使「取整棵子树」退化为一次前缀查询。评论树与菜单树几乎不发生子树移动，是该结构的最佳适用场景。
数据表清单
共 53 张表。点击任一行展开完整字段定义；也可用下方搜索框按表名或字段名定位。