评价表怎么设计才支持追评和修改
商品评价不能只建一张
comments表就完事。用户发完评价后可能退货、换货，或商家回复后想补充说明（即“追评”），这些都得在结构里留余地。
推荐用三张表组合：
product_reviews存主评价（含评分、内容、状态、创建时间）
review_replies存商家/平台对某条评价的回复（
review_id外键关联）
review_edits记录每次编辑（包括首次提交），字段含
review_id、
content、
edited_at、
is_latest布尔标记
不建议直接更新
product_reviews.content字段——历史内容丢失，审计困难，也容易引发并发覆盖问题。
如何防止刷评和重复提交
同一用户对同一商品只能有一条有效评价（追评不算新评），靠数据库唯一约束最可靠。
在
product_reviews表上建联合唯一索引：
UNIQUE KEY `uid_pid_status` (`user_id`, `product_id`, `status`)
其中
status是 tinyint，比如 1=有效，0=已删除，-1=待审核。这样用户删了再评，只要 status 变成 1，仍能被索引拦住。
额外建议：
插入前先查SELECT 1 FROM product_reviews WHERE user_id = ? AND product_id = ? AND status = 1，应用层提前拦截，减少死锁概率 不要依赖前端 JS 防重，必须服务端校验 对高频账号（如 1 小时内评 >5 单）加 Redis 计数限流，避免暴力插入
查商品评价时怎么兼顾性能和分页
用户打开商品页要查最新 10 条好评，后台导出要查全部带用户信息的评价——这两类查询模式差异大，别共用一个 SQL。
面向用户的接口（如商品详情页）：
只查product_reviews主表必要字段（
id、
rating、
summary、
created_at） 用
WHERE product_id = ? AND status = 1 ORDER BY created_at DESC LIMIT 10 OFFSET 0确保
(product_id, status, created_at)有联合索引，否则
LIMIT/OFFSET深翻页会变慢
管理后台导出全量：
用JOIN查用户昵称、订单号等扩展信息，但加
STRAIGHT_JOIN强制驱动表为
product_reviews避免
SELECT *，尤其别把大文本字段（如长评论）和用户头像 base64 一起查 如果数据超 10 万行，考虑用游标分页（
WHERE created_at ）替代 offset
评分统计怎么实时又不拖垮写入
每次新增/修改评价都去
UPDATE product SET avg_rating = (SELECT AVG(rating) FROM product_reviews WHERE product_id = ? AND status = 1)是灾难——锁表、慢、还容易不准。
正确做法是异步+缓存双写：
插入/更新评价后，仅触发一条消息（如 Kafka 或本地队列），由后台任务更新product.avg_rating和
review_count同时把最新均值写入 Redis，key 为
product:rating:{id}，过期设 10 分钟
读取时优先查 Redis，未命中再查 DB 并回填，避免缓存击穿
注意：Redis 的均值只是近似值，后台任务失败时可能滞后几秒，但对商品列表页的星级展示完全够用；真要强一致（比如结算页显示“已有 237 条评价”），就查
product_reviews的
COUNT(*)，别复用缓存。
追评不改变原始评分，所以不会触发重新计算——这点常被忽略，导致统计逻辑多算一次。
