一个能跑起来的评论系统，comments表至少需5个核心字段：id、post_id、content、created_at、status；其中id用BIGINT UNSIGNED AUTO_INCREMENT，post_id和user_id须加索引，content用TEXT，支持二级回复需parent_id（允许NULL并加索引）。
评论表必须包含哪些核心字段
一个能跑起来的评论系统，comments 表至少得有 id、post_id（关联文章）、content（正文）、created_at（时间）、status（审核状态）这 5 个字段。缺 status 容易被灌水；不加 post_id 就没法知道评论属于哪篇文章；created_at 不设默认值 CURRENT_TIMESTAMP，后期查数据会很被动。
常见错误：把用户信息（如昵称、邮箱）直接存进 comments 表。这样会导致修改用户资料时要批量更新评论表，也违背范式。正确做法是只存 user_id，再通过关联查用户表。
-
id类型用BIGINT UNSIGNED AUTO_INCREMENT，避免将来评论量大时溢出 -
post_id和user_id必须加索引，否则按文章查评论会变全表扫描 -
content推荐用TEXT，别用VARCHAR(1000)—— 用户真写长评时会被截断
如何支持二级回复（即“回复某条评论”）
靠一个 parent_id 字段就能实现。它默认为 0 或 NULL，表示一级评论；如果指向另一个 comments.id，就是二级回复。注意：这个字段必须允许为 NULL，且要加索引，否则查某条评论的所有子回复会极慢。
实际查询时，不能只靠一次 JOIN 拿到完整树形结构——MySQL 原生不支持递归 CTE（8.0+ 虽支持，但深度有限且性能差）。生产环境更推荐“查两次”：第一次查一级评论，第二次用 WHERE parent_id IN (…) 查所有子回复，应用层拼装。
CREATE TABLE comments ( id BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT, post_id BIGINT UNSIGNED NOT NULL, user_id INT UNSIGNED NOT NULL, parent_id BIGINT UNSIGNED NULL, content TEXT NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT '1=待审,2=通过,3=拒绝', created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, INDEX idx_post_id (post_id), INDEX idx_user_id (user_id), INDEX idx_parent_id (parent_id) );
防刷和基础审核怎么落地到建表和 SQL 层
数据库层面能做的有限，但几个关键约束能拦住明显异常：
- 对同一
post_id+user_id+content组合加唯一索引，防止用户重复提交相同评论 -
status字段用TINYINT而非VARCHAR，减少存储和比对开销 - 加
updated_at字段并设触发器自动更新，方便后台识别“被编辑过”的评论
注意：不要在数据库里做 IP 记录或频率限制——这些该由应用层或 Nginx 处理。MySQL 的 INSERT ... ON DUPLICATE KEY UPDATE 可用于幂等提交，但仅限简单场景；复杂逻辑（比如 5 分钟内只允许发 1 条）必须在代码里控制。
查询某篇文章的评论列表时最容易忽略的性能点
最常被忽视的是 ORDER BY created_at DESC LIMIT 20 这类语句没走对索引。即使有 idx_post_id，MySQL 仍可能先过滤再排序，导致 Using filesort。
解决办法是建联合索引：INDEX idx_post_status_time (post_id, status, created_at)。这样 WHERE post_id = ? AND status = 2 就能直接定位，再按 created_at 倒序取前 20 条，全程走索引。
另外，如果评论数超过 10 万，LIMIT 100000, 20 会越来越慢。这时要么改用游标分页（用上一页最后一条的 created_at 和 id 作为下一页条件），要么加缓存层，别硬扛。
