搭建留言板功能时，很多人第一反应是建一张表把昵称、内容、时间全塞进去，短期能跑通，但遇到楼中楼回复、用户禁言、内容审核就束手无策。用MySQL做底层存储，核心是把业务实体拆清楚：谁发的、发的是什么、挂在谁下面、当前状态如何。围绕这些维度来设计表，比盲目加字段更利于长期维护。
核心表结构设计思路
留言板至少包含三类实体：用户、留言主帖、回复或子留言。用户表独立出来可复用账号体系，避免每一条留言都重复存昵称与邮箱。留言主表负责承载根级内容，通过设置parent_id字段指向父留言编号，实现自关联树形结构，而不用为每层楼单独建表。状态字段用tinyint区分正常、待审、删除，配合逻辑删除减少外键断裂。
下面给出基础建表语句，字符集统一用utf8mb4以支持表情符号与中文。索引方面，在parent_id与created_at上建普通索引，加速层级查询与按时间排序。用户表密码相关字段此处省略，仅保留留言板所需最小集。
CREATE TABLE `mb_user` ( `id` INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, `nickname` VARCHAR(50) NOT NULL, `email` VARCHAR(100), `status` TINYINT NOT NULL DEFAULT 1, `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `mb_message` ( `id` BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, `user_id` INT UNSIGNED NOT NULL, `parent_id` BIGINT UNSIGNED DEFAULT 0, `content` TEXT NOT NULL, `status` TINYINT NOT NULL DEFAULT 1, `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX `idx_parent` (`parent_id`), INDEX `idx_time` (`created_at`), CONSTRAINT `fk_msg_user` FOREIGN KEY (`user_id`) REFERENCES `mb_user`(`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
上述结构中parent_id为0时表示根留言，大于0则表示某条留言的回复。此种设计让无限层级成为可能，前端用递归或闭包表缓存均可渲染。相比邻接表只存父级，还可后续引入path字段存全路径缩短查询，但初期用自关联已足够清晰。
回复与层级展示的查询方案
拿到自关联表后，常见需求是取出某主帖下的全部回复并按楼序排列。最简单做法是先查根留言，再按parent_id分批查子留言，避免用递归SQL拖垮数据库。数据量中等时，单次查全树用一条语句配合客户端组装也行，但深层嵌套建议用应用层循环处理。
以下示例展示如何获取某个主帖及其直接回复，并按时间正序排列。通过左连接用户表拿到昵称，用status过滤已删除内容。逻辑删除在这里体现为status != 2，物理记录保留以满足管理审计。
SELECT m.id, m.parent_id, m.content, u.nickname, m.created_at FROM mb_message m JOIN mb_user u ON m.user_id = u.id WHERE m.status != 2 AND (m.id = 12 OR m.parent_id = 12) ORDER BY m.parent_id ASC, m.created_at ASC;
若要做全文盖楼，可借助MySQL 8.0的CTE递归查询，但注意递归深度限制与性能。对于百万级留言，更合理的是异步生成扁平化列表存到缓存表，定时刷新。表结构本身不用变，只需在业务层加一个mb_thread_cache表存序列化后的树，降低数据库压力。
另一个易错点是删除主帖时子留言悬空。因为用了逻辑删除，主帖status置为2，子留言可同步标记为关联失效，或保留并前台隐藏。这样既不破坏外键，也方便后续恢复或导出。
性能优化与扩展字段实践
当留言板流量上涨，单表插入成为瓶颈。可按user_id或月份做分表，但分表后跨表统计需应用层合并。索引不是越多越好，content字段因类型TEXT不能整列索引，如需搜索可用FULLTEXT索引，语言设为中文ngram解析器提升命中率。
扩展方面，点赞数、举报数可放独立计数表，用message_id关联，防止频繁更新主表行锁。审核流则增加mb_audit_log表记录操作员与时间。下表对比两种删除策略差异，帮助选型。
| 策略 | 实现方式 | 优点 | 缺点 |
|---|---|---|---|
| 物理删除 | DELETE语句移除行 | 表体积小，查询快 | 关联断裂，无法恢复 |
| 逻辑删除 | status置位，查询过滤 | 可审计，易恢复 | 需每查询带条件，表膨胀 |
最后提醒，连接池配置与慢查询日志要打开，定位parent_id扫描是否走索引。用EXPLAIN分析执行计划，发现type为ALL时就该补索引。留言板虽小，却是检验MySQL建模能力的典型场景，把表结构想透，后续加私信、通知都不会乱。