新闻网站评论功能MySQL实现的核心是users、articles、comments三表结构，通过外键关联确保数据一致性，用parent_id支持嵌套回复，联合索引优化查询性能，并以status字段实现软删除与审核管理。
新闻网站的评论功能，核心是让每条评论能准确归属到某篇文章、某个用户，并支持基础互动（如回复、审核、排序）。用 MySQL 实现，关键不在“能不能做”，而在于表结构是否经得起真实流量和后续迭代——比如突然要加“评论点赞”“敏感词自动屏蔽”“按热度排序”，前期设计没留余地，后期就得改表、迁数据、停服务。
怎么建三张基础表：users、articles、comments
这是最轻量又最稳妥的起点。不推荐把用户信息冗余进 comments 表（比如直接存 username），否则用户改名时得同步更新所有历史评论，容易漏、难维护。
-
users表只存核心身份字段：user_id（主键，AUTO_INCREMENT）、username、email（可选）、created_at -
articles表聚焦内容本身：article_id（主键）、title、content、author_id（外键关联users.user_id）、published_at -
comments表是枢纽：comment_id（主键）、article_id（外键）、user_id（外键）、content（TEXT类型）、created_at、status（TINYINT，0=待审，1=已发布，-1=已屏蔽）
外键必须加：
ALTER TABLE comments ADD CONSTRAINT fk_article FOREIGN KEY (article_id) REFERENCES articles(article_id) ON DELETE CASCADE;否则删了新闻，评论还挂着，变成“孤儿数据”。
ON DELETE CASCADE 是安全兜底，但生产环境建议先软删（改 status）再定期归档。
为什么 parent_id 要设成自引用外键，而不是另建 reply 表
很多团队一开始觉得“评论”和“回复”是两类东西，就分两张表。结果很快发现：回复也能被回复（二级回复），三级嵌套怎么办？再建 reply_reply 表？逻辑爆炸。
- 用单表 +
parent_id字段，天然支持无限层级（实际业务中两层足够） -
parent_id类型设为INT UNSIGNED DEFAULT NULL，值为NULL表示一级评论；非空则指向同表的comment_id - 必须加自引用外键：
ALTER TABLE comments ADD CONSTRAINT fk_parent FOREIGN KEY (parent_id) REFERENCES comments(comment_id) ON DELETE CASCADE;
这样删掉某条评论，它的所有子回复也自动清理 - 别忘了给
parent_id加索引：INDEX(parent_id)，否则查某条评论的所有回复会全表扫描
哪些字段必须加索引，否则查评论时会卡死
新闻首页加载一条文章 + 20 条最新评论，看似简单，但没索引时，MySQL 可能要扫几万行才能凑够这 20 条。常见误判是“反正数据量小，先不加”。等日活过万、单篇热门新闻评论破千，就只能半夜改库。
-
comments.article_id：查某篇文章所有评论的入口，必加INDEX -
comments.created_at：按时间倒序取最新评论，单独建索引效果一般；更优是联合索引INDEX(article_id, created_at)，覆盖“查某文+按时间排”这个高频组合 -
comments.status：审核状态过滤（如只查status = 1），如果未审核评论占比高，这个字段选择性差，索引效率低；此时应配合WHERE status = 1再加ORDER BY created_at DESC，用联合索引覆盖
别碰 content 建全文索引——除非真要做站内评论搜索。普通展示场景下，它只会拖慢写入，且 LIKE '%关键词%' 依然走不了索引。
status 字段和软删除的实际代价
物理删除（DELETE FROM comments WHERE ...）看着干净，但会引发两个隐形问题：一是自增 ID 断层，暴露业务量（比如你看到 comment_id=100004 就知道至少发过十万条评论）；二是无法回溯“谁删了哪条”，审计困难。
- 用
status字段实现软删除是标准做法，但要注意：所有SELECT必须显式带上AND status = 1，漏一个就可能把审核中或已屏蔽的评论刷出来 - 后台管理页查“全部评论”可以查
status IN (0,1,-1)，但前端展示必须过滤 - 长期积累的
status != 1数据要定期归档（如导出到历史库再DELETE），否则comments表膨胀，即使加了索引，COUNT(*)都变慢
真正容易被忽略的，是时间字段的精度。用 DATETIME 没问题，但如果未来要支持毫秒级并发提交（比如直播新闻弹幕式评论），就得升到 DATETIME(3) 并确认 MySQL 版本 ≥5.6.4——老系统升级常在这儿翻车。
