评论表需支持嵌套层级，采用parent_id外键实现，禁止冗余字段和json存储；状态、ip哈希、缓存计数与游标分页为性能关键。
评论表必须带层级关系支持
如果只做一级评论（如博客留言），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 和索引对齐，并接受“最多展开两级”的产品妥协。 
