一个能跑起来的评论系统，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 层
数据库层面能做的有限，但几个关键约束能拦住明显异常：
部分功能简介：商品收藏夹功能热门商品最新商品分级价格功能自选风格打印结算页面内部短信箱商品评论增加上一商品，下一商品功能增强商家提示功能友情链接用户在线统计用户来访统计用户来访信息用户积分功能广告设置用户组分类邮件系统后台实现更新用户数据系统图片设置模板管理CSS风格管理申诉内容过滤功能用户注册过滤特征字符IP库管理及来访限制及管理压缩，恢复，备份数据库功能上传文件管理商品类别管理商品添加/修改/
- 对同一
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 作为下一页条件），要么加缓存层，别硬扛。
