构建一个基于MySQL的社交平台，核心并不只是把数据存进去，而是要在用户量增长之后依然保持关系查询、动态分发和互动统计的响应速度。社交业务有典型的写扩散与读扩散权衡，以及高度互联的用户关系，这决定了数据库schema与查询路径必须提前规划。
一、核心数据模型设计
社交平台最基础的实体是用户、关系、内容和互动。如果把这些全部揉进一张表，不仅字段冗余，还会让索引变得臃肿。更合理的办法是做垂直拆分：用户基础信息独立成表，关注关系单独成表，动态内容单独成表，点赞评论等互动再独立出来。这样每张表职责单一，便于后续分库分表。
以用户关系为例，关注关系具有方向性。如果我们只存一条“A关注B”的记录，那么查询“B的粉丝列表”就需要反向扫描，数据量大时很慢。常见优化是冗余存储，即同时写入“A关注B”和“B被A关注”两条记录，或者用一张关系表配合双向查询索引。下面是一张简化版的关系表结构：
CREATE TABLE user_relation ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, target_id BIGINT NOT NULL, relation_type TINYINT NOT NULL COMMENT '1关注2粉丝', created_at DATETIME NOT NULL, INDEX idx_user_type (user_id, relation_type), INDEX idx_target_type (target_id, relation_type) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
上面的表中，relation_type用来标记这条记录是关注还是粉丝，通过双索引让“我的关注”和“我的粉丝”都能走索引。实际实现中也可以直接拆成follow表和fans表，逻辑更清晰，但写的时候要注意事务一致，避免关注成功却没写入粉丝表。
内容表方面，动态通常包含发布者、正文、图片、时间等。由于社交平台读动态一般是按时间线拉取，因此时间字段必须参与索引。同时，为了支持“看某人主页”和“看关注流”两种读取，可考虑冗余发布者ID并配合联合索引。
二、动态分发的存储策略
社交平台发动态有两种典型模式：写扩散和读扩散。写扩散是指用户发一条动态，就往所有粉丝的收件箱里插一条记录，读的时候直接读自己的收件箱，读快写慢；读扩散是动态只存一份，读的时候临时去关注的人那里拉取再合并，写快读慢。MySQL更常配合写扩散思路做“推模式”的收件箱表，来缓解复杂查询。
下面是一张收件箱表的示例，用于存放每个用户时间线上的动态引用：
CREATE TABLE user_feed ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL COMMENT '接收动态的用户', post_id BIGINT NOT NULL COMMENT '动态ID', author_id BIGINT NOT NULL COMMENT '发布者ID', created_at DATETIME NOT NULL, INDEX idx_user_time (user_id, created_at) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
当用户A发布动态时，程序先写入post表，然后查出A的粉丝列表，批量插入user_feed。粉丝量极大时，这种写法会给主库带来压力，因此可改为异步队列处理，或者只对活跃粉丝写实时收件箱，其余走读扩散补全。这样能在性能和体验之间取得平衡。
对于历史数据，可按月份或用户ID哈希做分表。例如user_feed_202401、user_feed_202402，查询时根据时间路由。分表后要注意跨表统计类需求尽量少做，或者借助汇总表定时聚合。
三、索引与查询优化要点
MySQL社交查询里最频繁的是“取某用户时间线最新N条”和“取某动态下的评论列表”。这两类查询都必须避免文件排序和回表过多。以时间线查询为例，应该使用覆盖索引，把要返回的字段尽量包含在索引中。
比如用户主页动态查询：
SELECT post_id, created_at FROM user_feed WHERE user_id = 1001 ORDER BY created_at DESC LIMIT 20;
这个语句依赖idx_user_time索引，由于user_id和created_at都在索引里，且顺序是先等值后范围排序，MySQL可以直接走索引拿到结果，不需要额外排序。如果还要带author_id，可以建(user_id, created_at, author_id)的联合索引，减少回表。
评论列表一般挂在动态下，可按动态ID分区，并配合( post_id, created_at )索引。注意limit深翻页问题，社交场景应禁止使用offset翻页，而是用上一页最后一条的时间或ID做游标：
SELECT id, content, created_at FROM comment WHERE post_id = 555 AND id < 上一页最小ID ORDER BY id DESC LIMIT 20;
通过这种方式，无论翻到第几页，查询代价都稳定，不会随偏移量变大而变慢。同时，热点动态评论可放入缓存，降低MySQL读压力。
四、高并发下的实践建议
当社交平台进入高并发阶段，单纯靠MySQL单实例已经不够。常见架构是在数据库前加一层缓存，比如把用户关系、热门动态、个人资料放进去，读请求优先命中缓存。写请求仍落MySQL，但可通过消息队列削峰，把粉丝收件箱写入异步化。
另一个重点是避免大事务。关注操作和写收件箱如果放在一个事务里且粉丝几百万，会长时间锁表。应拆成：先写关系表返回成功，收件箱写入丢给后台任务，哪怕延迟几秒也是可接受的。对于关系链查询，还可以用邻接表配合闭包表思路，在MySQL里用额外路径表加速多层级关系查找。
最后，定期用慢查询日志和explain分析核心SQL。社交业务SQL往往不复杂，但数据倾斜严重，少数大V账号的查询量可能是普通用户的上千倍，需要针对这些账号做单独缓存或限流，保障整体可用性。
mysqlsocial_platform_designdatabase_optimization修改时间：2026-08-03 02:00:30