评论表必须含parent_id、root_id、depth字段以支持层级回复，配外键约束与复合索引，并用status软删除确保数据一致性与查询性能。
评论表必须带层级关系字段，否则无法支持回复
做评论功能最常踩的坑是只建一个扁平表，比如只有 id、content、user_id、created_at，结果发现“回复某条评论”时完全没法定位上下文。MySQL 本身不支持递归查询（8.0+ 才有 WITH RECURSIVE），所以得靠字段设计把关系显式存下来。
推荐结构里至少包含：parent_id（为 0 或 NULL 表示一级评论，否则指向被回复的那条 id）、root_id（该评论所属的最顶层评论 ID，方便按主题聚合）、depth（当前嵌套深度，用于前端限制最多回复几层）。
-
parent_id建BIGINT UNSIGNED+ 索引，避免 JOIN 时类型隐式转换 -
root_id和parent_id要保持一致：新评论若是一级，则root_id = id；若是回复，则root_id继承自其父评论的root_id - 不要用
path字段（如 "1/5/23"）模拟树——插入/移动成本高，且 MySQL 对字符串路径的索引效率差
用户和内容关联必须用外键约束，但要设 ON DELETE SET NULL
评论必然属于某个用户和某个目标（文章、视频、商品等）。很多人直接用 user_id 和 target_id，却不加外键，导致用户删了但评论还挂着脏数据，或者目标下架后评论仍显示“ID: 999999”。
正确做法是给 user_id 加外键，引用 users.id，但删除策略选 ON DELETE SET NULL；同理，target_id 引用对应内容表（如 articles.id），也设 SET NULL。这样既保证写入时数据合法，又避免级联删除误清评论。
-
user_id字段必须允许NULL，否则外键设SET NULL会失败 - 如果业务要求“用户注销后评论仍显示昵称”，就得额外加
username_snapshot字段存当时快照，不能只靠 JOIN 用户表查 - 别给
target_type（如 'article'/'video'）字段加外键——MySQL 不支持多态外键，用应用层校验更实际
高频查询场景决定索引组合，别只加单列索引
评论列表加载通常有三种请求：① 某篇文章下的所有一级评论（按时间倒序）；② 某条评论下的所有子评论（按时间正序）；③ 某用户发的所有评论（后台管理用）。单靠 INDEX(user_id) 或 INDEX(target_id) 无法覆盖这些场景。
必须建复合索引，并按查询条件顺序排列字段。例如，查文章下一级评论常用 WHERE target_id = ? AND parent_id = 0 ORDER BY created_at DESC，对应索引应为 INDEX(target_id, parent_id, created_at)；而查子评论是 WHERE parent_id = ? ORDER BY created_at ASC，就需要 INDEX(parent_id, created_at)。
- 别把
created_at放在复合索引第一位——几乎没人按全局时间查评论 -
status字段（如 0=正常、1=删除、2=审核中）必须参与索引：多数接口只查status = 0，索引应写成INDEX(target_id, parent_id, status, created_at) - 如果用
root_id查整棵评论树，记得给它单独建索引：INDEX(root_id, created_at)
软删除比物理删除更安全，但需统一处理逻辑
评论一旦被用户或管理员“删除”，大概率只是隐藏而非真删——因为可能涉及举报追溯、审计、或未来恢复。物理删除不仅破坏数据完整性，还会让 root_id、parent_id 关系链断裂。
用 status 字段实现软删除最稳妥。关键是要在所有读取评论的 SQL 里显式加上 AND status = 0，包括 JOIN 子查询、统计 COUNT、以及后台管理的“已删除”筛选页。漏掉一处，就可能出现数据不一致。
- 千万别在应用层靠 if 判断是否显示——数据库层面过滤才是唯一可信的
- 如果业务允许“用户只能删自己的评论”，注意
UPDATE comments SET status = 1 WHERE id = ? AND user_id = ?这类语句必须检查影响行数是否为 1 - 定期归档老数据（如 status=0 且 2 年前的）到历史表，避免主表膨胀拖慢查询
真正难的不是建表，而是所有增删改查逻辑都得围绕这个结构转：发评论要算 root_id 和 depth，查子评论要确认 parent_id 是否有效，后台导出要过滤 status……漏掉任意一环，前端就会出现“回复消失了”或“点开全是空数据”。
