在 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 表 + 应用层缓存计数
