评论表设计要支持分页、排序和软删除
旅游网站的用户评论通常需要按时间倒序展示，还要支持点赞、回复、审核状态等字段。直接用
CREATE TABLE comments加几个字段容易踩坑：比如没加
status字段导致无法下架违规评论，或没建
created_at索引让分页变慢。
推荐结构包含：
id（主键）、
user_id（评论人）、
spot_id（景点ID）、
content（TEXT类型）、
status（TINYINT，默认1=正常，0=已删/待审）、
created_at（DATETIME，带索引）、
updated_at（用于最后编辑时间）。
关键点：
status必须设为可空或默认值，避免用
DELETE FROM comments物理删数据
spot_id和
created_at要联合建索引，否则
WHERE spot_id = ? AND status = 1 ORDER BY created_at DESC LIMIT 20 OFFSET 40在万级数据时会变慢 别用
TEXT存图片路径——单独建
comment_images表更利于扩展和清理
查询最新10条评论时避免 OFFSET 性能陷阱
旅游页面常需“加载更多”，前端传
page=2&size=10，后端写
LIMIT 10 OFFSET 10看似简单，但 MySQL 实际要扫描前20行再丢弃前10行。当评论总量超50万，第500页就明显卡顿。
改用游标分页（cursor-based pagination）更稳：
SELECT id, user_id, content, created_at FROM comments WHERE spot_id = 123 AND status = 1 AND created_at < '2024-06-01 10:20:30' ORDER BY created_at DESC LIMIT 10;
要点：
前端下次请求带上上一页最后一条的created_at值（精度到秒足够） 必须确保
created_at不重复——旅游场景中同一秒多人评论极少见，若真发生，加
id作为第二排序条件 不能用
OFFSET的地方，也别依赖
ORDER BY RAND()抽样，它会全表扫描
插入评论前必须校验用户与景点关系
旅游网站常见逻辑是“只允许去过该景点的用户发评论”。如果只靠前端控制，绕过 JS 就能伪造
spot_id提交。MySQL 层面得做约束或检查。
有两种可靠做法：
在插入前查SELECT 1 FROM user_visits WHERE user_id = ? AND spot_id = ? AND visited_at IS NOT NULL，无结果则拒绝 建唯一联合索引
UNIQUE KEY (user_id, spot_id)配合业务逻辑，防止重复打卡，再把评论表外键指向
user_visits
注意：
user_visits表本身也要有
status字段，因为“预约未去”“取消行程”等情况不能算真实到访。
MySQL 8.0+ 可用 JSON 字段存扩展属性但别滥用
旅游评论偶尔需要动态字段，比如“是否带娃出游”“是否冬季来访”“推荐季节”等。用传统加列方式太僵硬，JSON 类型看起来方便：
ALTER TABLE comments ADD COLUMN meta JSON;
但实际要注意：
JSON 字段无法被普通索引覆盖，想按meta->'$.with_kids'查询必须建生成列 + 索引：
ALTER TABLE comments ADD COLUMN with_kids TINYINT AS (meta->'$.with_kids') STORED;
CREATE INDEX idx_with_kids ON comments(with_kids);别把高频查询字段（如评分、标签）塞进 JSON，否则
WHERE meta->>'$.rating' > 4无法走索引，且 JSON 解析开销比普通字段高 备份和迁移时 JSON 内容可能被格式化或截断，尤其含 emoji 或特殊编码时
真正需要灵活结构的场景（比如多语言评论摘要），更适合用独立的
comment_metadata表，而不是堆 JSON。
