推荐用三张表组合：product_reviews存主评价，review_replies存商家回复，review_edits记录每次编辑并标记最新版本；通过联合唯一索引(user_id, product_id, status)防止重复评价，服务端校验+Redis限流防刷评；查评价时区分场景——用户端走覆盖索引高效分页，后台导出用STRAIGHT_JOIN避免关联性能问题。
评价表怎么设计才支持追评和修改
商品评价不能只建一张 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(*)，别复用缓存。
追评不改变原始评分，所以不会触发重新计算——这点常被忽略，导致统计逻辑多算一次。
