MySQL 评论系统需设计支持多类型目标的泛型表，含 target_type/target_id/user_id/parent_id/status 等核心字段，建组合索引提升查询效率，采用两步查询 + 后端组装实现二级嵌套展示，并通过 status 软删除、敏感词过滤、独立点赞表等保障健壮性。
在 MySQL 中实现一个健壮的评论系统，核心在于表结构设计合理、支持嵌套 / 回复、兼顾查询效率与数据一致性。下面从实际开发角度出发，给出一套经过验证的评论表设计方案和关键实现要点。
评论表基础字段设计
一张评论表需覆盖基本业务需求：谁在哪条评论了什么、何时评的、是否被删除等。推荐字段如下：
- id：主键，BIGINT 自增或 UUID（高并发下建议用雪花 ID 或数据库自增）
- target_type：评论目标类型（如 ‘article’、’video’、’product’），便于多类型内容复用同一张表
- target_id：目标记录 ID（对应文章 ID、视频 ID 等），配合 target_type 实现泛型关联
- user_id：评论用户 ID（关联用户表），非空
- parent_id：父评论 ID，为 0 或 NULL 表示一级评论；大于 0 表示对某条评论的回复（支持二级嵌套足够常见场景）
- content：评论内容，TEXT 类型，注意字符集设为 utf8mb4 支持 emoji
- status：状态字段，TINYINT，如 0= 待审核、1= 已发布、2= 已屏蔽、3= 已删除（软删除更安全）
- created_at、updated_at：时间戳，自动维护
关键索引与性能优化
没有索引的评论表在数据量过万后会明显变慢。必须建立以下组合索引：
- (target_type, target_id, status, created_at)：查某篇文章下所有正常评论，按时间倒序
- (parent_id, status, created_at)：查某条评论下的全部回复，也按时间倒序
- (user_id, status, created_at)：查某用户发过的评论（个人中心场景）
- 单独为 target_id 加索引（若不走组合索引前缀，可辅助加速）
避免在 content 字段建全文索引（除非真有搜索需求），否则写入开销大、维护复杂。
处理评论回复与层级展示
MySQL 原生不支持无限级树查询，但绝大多数评论场景只需「一级评论 + 一层回复」。推荐做法是：
- 查文章评论时，分两步：先查 parent_id = 0 的一级评论，再用这些评论的 id 集合查 parent_id IN (……) 的回复
- 后端 组装成树形结构（如 {comment: {…}, replies: […] }），前端 递归渲染
- 如需查某条评论及其所有子孙（极少见），可用存储过程或应用层多次查询（不建议深嵌套）
防刷、审核与扩展建议
上线前务必考虑运营与安全维度：
- 加 ip_hash 或 user_agent + ip 字段，辅助识别机器刷评（不替代风控服务）
- 敏感词过滤放在应用层，MySQL 不适合做实时文本扫描
- 审核流程通过 status 字段控制，后台可批量操作；日志另存 audit_log 表，保留操作人和时间
- 后续想支持点赞，不要直接加 like_count 字段（并发更新易出错），改用独立的 like_record 表 + 应用层缓存计数
