核心表只需用户、文章、评论三张：users含id、username、password_hash、email；posts含id、title、content、author_id、created_at；comments含post_id、user_id。
博客系统该建哪些表
核心表就三张：用户、文章、评论，别一上来就加标签表、分类表、收藏表——多数个人博客根本用不上。先跑通基础功能再扩展。
用户表 users 至少包含 id（主键）、username、password_hash（别存明文！）、email；文章表 posts 要有 id、title、content（建议用 TEXT 类型）、author_id（外键关联 users.id）、created_at（用 DATETIME 或 TIMESTAMP）；评论表 comments 记住必须带 post_id 和 user_id，否则查不出来是谁在哪个文章下评的。
怎么让文章按时间倒序且分页查
MySQL 默认不保证顺序，SELECT * FROM posts 可能每次结果都不一样。必须显式写 ORDER BY created_at DESC。
分页别直接用 LIMIT 20,10 做深分页——第 1000 页时性能会断崖下跌。真实项目里更推荐「游标分页」：记录上一页最后一条的 created_at 和 id，下一页查 WHERE created_at 。
-
created_at加联合索引：INDEX idx_created_id (created_at, id) - 避免
SELECT *，只查需要字段，尤其content很大时 - 如果用
LIMIT offset, size，offset > 5000就该警觉了
评论怎么防刷和关联数据
没做任何限制的评论接口，半小时就能被灌几千条垃圾数据。至少加两道卡：
一是数据库层加约束：comments 表的 post_id 必须存在对应文章（加外键 FOREIGN KEY (post_id) REFERENCES posts(id) ON DELETE CASCADE），user_id 同理；二是应用层控制频率，比如单个 user_id 每分钟最多发 5 条，这个不能只靠 MySQL 实现，得配合 Redis 计数。
另外，删文章时如果没设 ON DELETE CASCADE，评论会变成“孤儿记录”，后续查文章详情时 JOIN 一查就漏数据，或者报错。
全文搜索用 LIKE 还是 MATCH AGAINST
用 LIKE '%关键词%' 查标题或内容，基本等于放弃性能——全表扫描，百万级数据就卡死。MySQL 原生支持中文全文索引，但要注意两点：
第一，必须用 MyISAM 或 InnoDB（5.6+），且字段类型是 TEXT 或 VARCHAR；第二，建表时得显式加 FULLTEXT(title, content) 索引，之后才能用 MATCH(title, content) AGAINST('搜索词' IN NATURAL LANGUAGE MODE)。
不过 MySQL 内置全文对中文分词很弱（按字切，不是按词），真要搜“数据库优化”，可能匹配不到“数据库”或“优化”单独出现的记录。小项目够用，稍大一点建议导出到 Elasticsearch 或用 Meilisearch。
外键要不要开、索引建在哪、分页用游标还是偏移量——这些不是理论问题，是上线后第一条慢查询报警就逼你改的实操点。别等堆完所有表再测试，建完 posts 和 comments 就立刻压测插入和关联查询，比看十篇教程都管用。
