评论表必须带复合索引，否则查询会越来越慢
用户评论量一上来，
SELECT * FROM comments WHERE post_id = ? ORDER BY created_at DESC LIMIT 20就容易变慢。单纯在
post_id或
created_at上建单列索引效果有限。
实际应建联合索引：
ALTER TABLE comments ADD INDEX idx_post_time (post_id, created_at DESC);MySQL 8.0+ 支持降序索引，
created_at DESC能让
ORDER BY created_at DESC直接走索引，避免 filesort 如果用的是 MySQL 5.7，去掉
DESC（它被忽略），靠
post_id前导列 + 覆盖排序范围也能显著提速 别忘了给
user_id单独加索引——用于查某人发过哪些评论，或做用户维度统计
软删除字段要用 TINYINT(1) + 默认值，别用 NULL
评论被“删除”通常只是隐藏，不是真删。用
is_deleted TINYINT(1) DEFAULT 0比
is_deleted ENUM('0','1') 或 is_deleted BOOLEAN更稳妥，也比允许
NULL更利于索引利用。
WHERE is_deleted = 0可走索引；
WHERE is_deleted IS NOT NULL在某些版本下可能无法使用索引 查询时所有带条件的 SQL 都要显式加上
AND is_deleted = 0，漏掉就会暴露已删评论 如果业务需要“回收站”功能，可额外加
deleted_at DATETIME NULL，但注意它不能和
is_deleted一起作为联合索引前导列（NULL 值影响索引选择性）
内容字段用 TEXT 还是 MEDIUMTEXT？看是否支持图片链接或长回复
纯文字评论，
TEXT（最大 64KB）够用；但如果允许用户粘贴 Markdown、插入图片 URL、甚至内嵌短代码，建议直接上
MEDIUMTEXT（16MB）。
TEXT类型字段不会自动加索引，全文搜索需额外建
FULLTEXT索引，且仅对 MyISAM 或 InnoDB（5.6+）有效 如果后续要支持关键词高亮或模糊搜索，别依赖
LIKE '%xxx%'—— 它无法用普通索引，应考虑
MATCH(content) AGAINST('xxx' IN NATURAL LANGUAGE MODE)
敏感词过滤、XSS 过滤必须在应用层做，数据库不负责内容清洗
点赞数不要实时 COUNT，用冗余字段 + 事务更新
每次查评论都
SELECT c.*, (SELECT COUNT(*) FROM comment_likes WHERE comment_id = c.id) AS like_count是典型 N+1 和性能陷阱。 在
comments表里加
like_count INT UNSIGNED DEFAULT 0字段，写入/取消点赞时用
UPDATE comments SET like_count = like_count + 1 WHERE id = ?点赞记录单独存
comment_likes(user_id, comment_id, created_at)，联合主键防重复，再加
INDEX idx_comment (comment_id)支持反查谁点过 如果点赞量极大（比如单条评论百万赞），
like_count字段可能成为热点行，要考虑分库分表或改用 Redis 计数后定时落库
真实场景里最容易被忽略的是：评论时间戳用
DATETIME还是
TIMESTAMP？前者无时区转换、范围大（1000–9999），后者自动转时区但范围窄（1970–2038），且受 MySQL 时区配置影响。业务若跨多时区，优先选
DATETIME并在应用层统一用 UTC 存储。
