评论表必须添加status字段并设默认值0（pending），推荐tinyint(1)类型，建索引idx_status，并在查询时强制where status = 1过滤，审核用原子update带状态条件，软删替代硬删以防数据不一致。
评论表必须加 status 字段并设默认值
不加审核状态字段，后续无法区分待审、已通过、已拒绝的评论。直接在评论表里加 status，类型用 TINYINT(1) 或 enum('pending','approved','rejected') 都可以，但推荐前者——整数比字符串索引效率高，且方便后期扩展（比如加“待人工复核”状态）。status 默认值设为 0（对应 pending），避免插入时漏填导致脏数据。
常见错误是把审核逻辑全放在应用层判断，数据库表里却没留字段，结果上线后加字段要锁表、改代码、补迁移脚本，三处都得动。
ALTER table comments ADD column status TINYINT(1) NOT NULL default 0 AFTER content;- 已有数据需补默认值：
UPDATE comments SET status = 0 WHERE status IS NULL; - 建索引提升查询效率：
CREATE INDEX idx_status ON comments(status);
审核操作要用 UPDATE + WHERE + 主键，别用 select + UPDATE
后台管理员点“通过”时，常见写法是先 SELECT * FROM comments WHERE id = 123，再在应用里拼 UPDATE comments SET status = 1 WHERE id = 123。这多一次网络往返，还可能被并发修改绕过（比如两人同时操作同一条评论）。
正确做法是一条原子语句完成状态变更，并校验原始状态可选：
UPDATE comments SET status = 1 WHERE id = 123 AND status = 0;执行后检查 ROW_COUNT() 返回值：如果是 0，说明该评论已被他人处理或状态不是 pending，前端可提示“操作失败，请刷新”。
- 避免用
WHERE id = ?不带状态条件，否则可能误更新已审核过的评论 - 不要在 UPDATE 中写
status = status + 1这类表达式，语义不清且易出错 - 如果需记录审核人和时间，一并更新：
SET status = 1, reviewed_by = 55, reviewed_at = NOW()
前台展示只查 status = 1 的评论，别用应用层过滤
用户看到的评论列表，sql 必须带 WHERE status = 1。哪怕你用 ORM、用框架封装了“审核通过”逻辑，最终生成的 SQL 也得落在数据库层面过滤。
否则，一旦评论量上来，每次查 1000 条再在 PHP/Java 里循环 Filter，既浪费内存又拖慢响应。mysql 的 B+ 树索引对 status 过滤非常高效，前提是字段有索引且查询条件明确。
- 错误示例：
SELECT * FROM comments WHERE post_id = 456→ 应用层再筛status === 1 - 正确示例：
SELECT id, content, created_at FROM comments WHERE post_id = 456 AND status = 1 ORDER BY created_at DESC LIMIT 20; - 若还需按时间倒序分页，注意
status = 1和created_at联合索引更优：INDEX idx_status_created (status, created_at)
定时清理 rejected 评论要考虑外键与磁盘空间
长期积压的 status = 2（rejected）评论，有些业务允许定期归档或物理删除。但直接 delete FROM comments WHERE status = 2 很危险——如果该评论有关联点赞、举报、回复，又没设外键约束或级联动作，就会留下孤立数据。
更稳妥的做法是软删 + 定期归档：
- 新增
deleted_at DATETIME NULL字段，删时用UPDATE ... SET deleted_at = NOW() - 归档脚本用
INSERT INTO comments_archive SELECT * FROM comments WHERE deleted_at IS NOT NULL LIMIT 1000分批搬 - 确认归档成功后再
DELETE FROM comments WHERE deleted_at IS NOT NULL LIMIT 1000 - 务必在凌晨低峰期跑，且监控
innodb_row_lock_time_avg，避免长事务阻塞线上写入
真正容易被忽略的是 binlog 日志暴增：一次删几万行，binlog 可能瞬间涨几百 MB，主从延迟飙升。所以批量删必须加 LIMIT，且间隔 sleep。