先设计帖子表和回复表结构，确保主帖与回帖分离且支持嵌套回复。1. 帖子表（posts）包含id、title、content、user_id、时间字段、reply_count和status等，用于存储主题帖并冗余关键统计字段提升性能；2. 回复表（replies）通过post_id关联主帖，parent_id实现楼中楼回复，配合created_at和索引优化查询效率；3. 关键设计包括复合索引、软删除支持、冗余字段减少JOIN操作，并可扩展@功能和点赞附件等模块，整体结构简洁高效，适用于多数论坛场景。
设计论坛的帖子和回复表结构，关键是要清晰区分主题帖（主帖）和回复帖（回帖），同时保证数据可扩展、查询高效。以下是实用的MySQL表结构设计方案。
1. 帖子表（posts）
存储主题帖信息，每条记录代表一个独立的话题。
- id：主键，自增整数，唯一标识每个帖子
- title：帖子标题，VARCHAR(255)
- content：帖子内容，TEXT类型
- user_id：发帖用户ID，关联用户表
- created_at：发帖时间，DATETIME或TIMESTAMP
- updated_at：最后修改时间，用于编辑更新
- last_reply_at：最新回复时间，便于排序（如按活跃度）
- reply_count：回复数量，冗余字段提升查询性能
- status：状态（正常、删除、屏蔽等），TINYINT
2. 回复表（replies）
存储所有对帖子的回复，包括楼中楼回复。
- id：主键，自增
- post_id：外键，关联帖子表的id
- user_id：回复用户ID
- parent_id：父级回复ID，实现楼中楼（NULL表示直接回复主帖）
- content：回复内容，TEXT
- created_at：回复时间
- floor：楼层号，可选，用于显示第几楼
- status：回复状态
3. 关键设计说明
这种结构能支持常见论坛功能，同时兼顾性能和扩展性。
- 用 parent_id 实现无限层级的嵌套回复，通过递归或程序层处理层级展示
- 在 replies 表上建立复合索引：(post_id, created_at)，加快按时间查询回复的速度
- 冗余 reply_count 和 last_reply_at 可避免频繁JOIN统计，提升列表页性能
- 若需要@功能，可在 replies 中加 at_user_id 字段
- 考虑软删除时，用 status 字段标记而非物理删除
4. 示例SQL片段
创建基本表结构示例：
CREATE TABLE posts ( id INT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(255) NOT NULL, content TEXT, user_id INT NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, last_reply_at TIMESTAMP, reply_count INT DEFAULT 0, status TINYINT DEFAULT 1, INDEX idx_user (user_id), INDEX idx_last_reply (last_reply_at) );CREATE TABLE replies ( id INT AUTO_INCREMENT PRIMARY KEY, post_id INT NOT NULL, user_id INT NOT NULL, parent_id INT NULL, -- NULL表示回复主帖 content TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, floor INT, -- 可通过程序计算填充 status TINYINT DEFAULT 1, FOREIGN KEY (post_id) REFERENCES posts(id), FOREIGN KEY (parent_id) REFERENCES replies(id), INDEX idx_post_time (post_id, created_at), INDEX idx_parent (parent_id) );
基本上就这些，结构简单但能满足大多数论坛需求。后续可根据业务加点赞、附件、标签等功能表。
