旅游网站评论表需支持分页、排序和软删除，核心字段包括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;
要点：
- 前端下次请求带上上一页最后一条的
created_at值（精度到秒足够） - 必须确保
created_at不重复——旅游场景中同一秒多人评论极少见，若真发生，加id作为第二排序条件 - 不能用
OFFSET的地方，也别依赖ORDER BY RAND()抽样，它会全表扫描
插入评论前必须校验用户与景点关系
旅游网站常见逻辑是“只允许去过该景点的用户发评论”。如果只靠前端控制，绕过 JS 就能伪造 spot_id 提交。MySQL 层面得做约束或检查。
