博客系统核心表有哪些，为什么必须分表
单表存所有内容看似简单，但实际会导致 posts
表膨胀过快、查询变慢、锁竞争加剧。真实博客系统至少要拆出四张基础表：users
（用户）、posts
（文章）、categories
（分类）、tags
（标签）。其中 posts
和 tags
是多对多关系，必须通过中间表 post_tags
关联——漏掉这张表，后期加标签筛选就只能用 LIKE
模糊匹配，性能直接崩。
常见错误是把标签当字符串塞进
posts.tag_list字段，比如存成
"mysql,python,web"。这违反第一范式，无法索引、不能原子增删、JOIN 查询失效。
user 表和 post 表的字段怎么定才不踩坑users
表必须有 id
（主键，BIGINT UNSIGNED
，避免未来 ID 超出 INT
上限）、username
（唯一索引）、email
（可选唯一）、password_hash
（不是明文密码）、created_at
（DATETIME
或 TIMESTAMP
，推荐后者，自动时区处理更稳）。
posts表关键字段包括：
id、
user_id（外键，指向
users.id）、
title（
VARCHAR(200)足够）、
slug（用于 URL，如
"how-to-use-mysql-index"，加唯一索引）、
content（用
LONGTEXT，别用
TEXT，防超长 Markdown 渲染内容）、
status（
ENUM('draft','published','archived') 或 TINYINT，比字符串查得快）、
published_at（允许为 NULL，草稿时不填）。
CREATE TABLE posts (
id BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
user_id BIGINT UNSIGNED NOT NULL,
title VARCHAR(200) NOT NULL,
slug VARCHAR(200) NOT NULL UNIQUE,
content LONGTEXT NOT NULL,
status ENUM('draft','published','archived') DEFAULT 'draft',
published_at DATETIME NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
);
分类与标签的关联逻辑怎么实现才高效categories
是树形结构？先别急着加 parent_id
。大多数博客只有平级分类（如“数据库”“前端”“运维”），用单层表 + posts.category_id
外键即可。真需要多级，再考虑闭包表或路径枚举，别一上来就搞复杂。
tags必须独立成表，并配中间表：
tags：
id、
name（
VARCHAR(50)，加唯一索引，防重复标签）
post_tags：
post_id、
tag_id，联合主键 + 双向索引（
(post_id, tag_id)和
(tag_id, post_id)）
这样查「某标签下的所有文章」就是：
SELECT p.* FROM posts p JOIN post_tags pt ON p.id = pt.post_id WHERE pt.tag_id = ? AND p.status = 'published';
如果只建了
(post_id, tag_id)索引，上面这个查询会全表扫
post_tags——因为 WHERE 条件走的是
tag_id，而索引最左前缀不匹配。
实际写入和查询时哪些 MySQL 配置容易被忽略innodb_buffer_pool_size
必须设为物理内存的 50%–75%，否则缓存太小，每次查 content
都读磁盘。
max_allowed_packet要调大（比如
64M），否则插入带大图 Base64 的 Markdown 内容会报错
Packet for query is too large。
全文搜索不用等 Elasticsearch。MySQL 5.6+ 原生支持中文需搭配
ngram插件：
ALTER TABLE posts ADD FULLTEXT(title, content) WITH PARSER ngram;
SELECT * FROM posts WHERE MATCH(title, content) AGAINST('mysql 索引' IN NATURAL LANGUAGE MODE);
但注意：
ngram对英文分词不友好，混合内容建议还是上 ES 或 Meilisearch。
字段默认值、时间类型、外键行为、索引覆盖、字符集（一律
utf8mb4_unicode_ci）——这些细节没调好，上线后改起来比重构还疼。
