旅游网站评论表需支持分页、排序和软删除，核心字段包括id、user_id、spot_id、content、status、created_at、updated_at；spot_id与created_at需联合索引；推荐游标分页替代OFFSET；插入前须校验user_visits关系；JSON字段慎用，高频查询字段应单独建列并索引。
评论表设计要支持分页、排序和软删除
旅游网站的用户评论通常需要按时间倒序展示，还要支持点赞、回复、审核状态等字段。直接用 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;
要点：
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 前端下次请求带上上一页最后一条的
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。
