评论表必须加 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。
