高扩展性社交数据库设计需同步进行E-R建模与反范式优化：明确拆分用户、动态、互动行为等实体，弃用外键改由应用层保障一致性，以user_id为统一分片键构建feed_timeline等宽表，并将带状态的关系独立建表分片。
高扩展性社交应用的数据库设计，不能只靠堆索引或换存储引擎解决——核心矛盾是「关系密集、读多写少、实时性要求高」，E-R建模定结构边界，反范式破连接瓶颈，二者必须同步决策，不是先范式再“打补丁”。
ER图里别画“用户动态”这种模糊实体
很多团队一上来就建 user_post 表，字段塞满内容、图片URL、点赞数、评论数、转发数……这已经不是建模，是把业务逻辑硬编码进表结构。ER图中应明确拆出：用户（user）、动态（post）、互动行为（like、comment、share）三类实体，关系用菱形标注基数，比如“用户-动态”是一对多，“动态-点赞”是多对一。
容易踩的坑：
- 把“热门标签”“话题聚合”当成独立实体画进ER图，但实际它只是
post的属性集合+缓存策略，不该落地为实体表 - 忽略软删除场景：所有含用户生成内容的实体（如
comment）必须预留is_deleted字段，否则后续加逻辑会牵连ER关系重绘 - 用“时间线”作为实体——它根本不是数据实体，而是查询结果，ER图里不该出现
3NF足够，但得主动放弃外键约束
第三范式能消除传递依赖，比如用户资料不直接存城市名，而是通过 city_id 关联 city 表，这在单库单实例时很干净。但社交应用一旦分库分表，跨库 FOREIGN KEY 在 MySQL 中无法生效，强行开启只会让 INSERT 变慢、事务变脆、迁移失败率飙升。
实操建议：
- 外键只保留在ER图和文档中，用注释形式写在建表语句里，例如：
-- FK: user_id → user(id), enforced by app logic -
user表的province_id和city_id字段允许为NULL，避免因地区表未同步导致注册流程中断 - 所有关联查询必须带
LEFT JOIN+COALESCE()处理空值，不能依赖数据库级级联
反范式不是加冗余字段，而是按访问路径预聚类
典型错误是往 post 表里加 author_nickname、author_avatar —— 这看似省JOIN，实则制造更新风暴：用户改头像要批量更新几千条动态记录。真正有效的反范式，是按高频查询路径构造宽表，且只存不可变或低频变更字段。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
例如：
- 为信息流页（feed）单独建
feed_timeline表，字段包括：user_id、post_id、post_type、created_at、score（预计算热度），主键为(user_id, created_at)，按用户分片 -
user_follow表除基础字段外，加follow_status（0=正常，1=互关，2=单向）——这个状态由关注/被关注双写触发，但只读场景免去两次JOIN查双方关系 - 绝不反范式存储计数类字段（如
like_count）到post表，改用 Redis 原子操作 + 异步落库，否则高并发点赞下UPDATE post SET like_count = like_count + 1成性能黑洞
分片键必须同时出现在ER关系和反范式表中
社交应用扩展的核心是水平拆分，但分片键选错等于自废武功。常见错误是用 post.id 分片，结果粉丝时间线查询要跨所有分片拉取数据。正确做法是：所有与用户强相关的实体（post、comment、like、feed_timeline）都以 user_id 为分片键，并在ER图中显式标出该键如何穿透各关系边。
关键细节：
-
feed_timeline表必须包含target_user_id（被刷到动态的用户）和source_user_id（发动态的用户），前者用于分片路由，后者用于权限校验 - 多对多关系如“用户-话题”，中间表
user_topic的主键必须是(user_id, topic_id)，且user_id放前位——保证按用户查询时能走索引局部扫描 - 任何反范式宽表若含多个用户ID字段（如
author_id、receiver_id），只以其中一个作为分片依据，另一个必须降级为普通索引，否则分片逻辑混乱
最易被忽略的一点：ER图里的“关系”在物理层未必对应一张表，尤其当关系本身带权重、时效或状态（如“用户A对帖子B的屏蔽状态”），这类关系必须独立建表并参与分片，不能压缩进任一端实体——否则分片后无法定位数据，也丧失状态变更的原子性保障。
