评论表必须带层级关系支持
如果只做一级评论（如博客留言），
comment表只需
id、
post_id、
user_id、
content、
created_at。但实际项目中，回复评论（二级甚至嵌套）很常见，硬编码“父评论ID”字段比用闭包表或路径字符串更可控。
parent_id设为
BIGINT UNSIGNED NULL，指向本表
id，允许为
NULL表示根评论 避免用
path字段（如
"1/5/23"）——更新移动成本高，且 MySQL 8.0 以前无原生路径函数支持 加索引：
INDEX idx_post_parent (post_id, parent_id)，覆盖最常用查询：「查某篇文章所有根评论」和「查某条评论下的全部子评论」
用户与内容解耦，别直接存用户名
评论表里不要出现
username或
avatar_url这类冗余字段。一旦用户改名或头像，历史评论就不同步。正确做法是只存
user_id，关联到独立的
user表。
user_id必须是外键（
FOREIGN KEY），并设
ON DELETE RESTRICT—— 防止误删用户导致评论变成“幽灵数据” 若业务要求“用户注销后评论仍保留署名”，可在用户删除时触发
BEFORE DELETE触发器，把当前
username快照写入评论表新增的
author_snapshot字段（
VARCHAR(64)） 不建议用
JSON字段存用户信息——丧失索引能力，也违背第三范式
防刷与状态控制不能靠应用层硬编码
评论是否可见、是否被屏蔽、是否需审核，这些状态必须落在数据库字段里，而不是靠后端 if-else 判断
status === 'approved'后再拼 SQL。 加
status字段，类型用
TINYINT UNSIGNED（非 ENUM）：
0=waiting、
1=approved、
2=blocked、
3=deleted加
ip_hash字段（
BINARY(16)），存
INET6_ATON()转换后的客户端 IP，用于限流和识别异常行为 查列表时务必在 WHERE 中显式过滤：
WHERE status = 1 AND post_id = ?，别依赖应用层二次过滤
大流量下 count(*) 和深度分页要提前规避
当单篇文章评论超 10 万条，
SELECT COUNT(*) FROM comment WHERE post_id = ?会变慢；
LIMIT 100000, 20更是灾难。解决方案不是加索引，而是换思路。 用缓存计数：每次插入/删除评论，同步
UPDATE post SET comment_count = comment_count + 1 WHERE id = ?分页不用 OFFSET，改用游标（cursor）：查第一页传
created_at > '1970-01-01'，之后每页传上一页最后一条的
created_at和
id，WHERE 写成
WHERE post_id = ? AND (created_at, id) > (?, ?) ORDER BY created_at, id LIMIT 20评论数超 5000 条后，前端默认只加载前 50 条，点“查看更多”才拉取更多——减少首屏压力
CREATE TABLE `comment` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, `post_id` BIGINT UNSIGNED NOT NULL, `user_id` BIGINT UNSIGNED NOT NULL, `parent_id` BIGINT UNSIGNED NULL, `content` TEXT NOT NULL, `status` TINYINT UNSIGNED NOT NULL DEFAULT 1, `ip_hash` BINARY(16) NULL, `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_post_parent` (`post_id`, `parent_id`), KEY `idx_user_status` (`user_id`, `status`), CONSTRAINT `fk_comment_post` FOREIGN KEY (`post_id`) REFERENCES `post` (`id`) ON DELETE CASCADE, CONSTRAINT `fk_comment_user` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`) ON DELETE RESTRICT ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;MySQL 的评论建模难点不在字段设计，而在状态流转和查询边界。很多人卡在“怎么查某条评论的所有回复”，其实关键不是递归 SQL（MySQL 8.0+ 才有 CTE 支持），而是从一开始就把
parent_id和索引对齐，并接受“最多展开两级”的产品妥协。
