推荐用三张表组合：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。
部分功能简介：商品收藏夹功能热门商品最新商品分级价格功能自选风格打印结算页面内部短信箱商品评论增加上一商品，下一商品功能增强商家提示功能友情链接用户在线统计用户来访统计用户来访信息用户积分功能广告设置用户组分类邮件系统后台实现更新用户数据系统图片设置模板管理CSS风格管理申诉内容过滤功能用户注册过滤特征字符IP库管理及来访限制及管理压缩，恢复，备份数据库功能上传文件管理商品类别管理商品添加/修改/
面向用户的接口（如商品详情页）：
- 只查
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(*)，别复用缓存。
追评不改变原始评分，所以不会触发重新计算——这点常被忽略，导致统计逻辑多算一次。
