用 MySQL 建知识库表，核心就三张表
知识库管理系统不需要一上来就搞全文检索或权限树，先跑通「存文章、分分类、打标签」这三件事。MySQL 8.0+ 足够支撑中小团队的内部知识沉淀，关键不是堆功能，而是字段设计别踩坑。
最简可用结构是：
kb_article（文章主表）、
kb_category（分类表）、
kb_tag（标签表），加上一个中间表
kb_article_tag实现多对多。分类用单级就够了，别一上来就设计成无限极递归——
parent_id字段留着，但初期设为
NULL或固定值更稳。
kb_article.id必须是
BIGINT UNSIGNED AUTO_INCREMENT，避免后期数据量涨了溢出
kb_article.content用
MEDIUMTEXT，别用
TEXT——后者最大 64KB，富文本粘贴几段代码就超限
kb_category.name加唯一索引：
UNIQUE KEY uk_name (name)，防止运营手动录入重复分类 标签名（
kb_tag.name）同样加唯一索引，且统一小写存储（插入前用
LOWER()处理），避免 “MySQL” 和 “mysql” 被当成两个标签
INSERT 和 UPDATE 时要防空内容和 XSS 风险
知识库内容来自人工录入，
INSERT INTO kb_article不能直接把富文本 HTML 塞进去就完事。MySQL 不过滤、不转义，前端渲染时容易触发 XSS —— 尤其当知识库开放给非管理员角色查看时。
实操建议：后端入库前做两件事：截断空格/换行开头结尾、剥离 script/style 标签及 on\* 事件属性。数据库层只做兜底：
给kb_article.title加
CHECK (LENGTH(TRIM(title)) > 0)（MySQL 8.0.16+ 支持）
kb_article.status设为
TINYINT DEFAULT 1，1=草稿，2=已发布，避免未审核内容被查出来 别在 SQL 里拼接用户输入的
category_id，一律用预处理参数传入，防止注入绕过应用层校验
查询知识条目时，ORDER BY 和 LIMIT 别乱用
常见错误是写
SELECT * FROM kb_article ORDER BY created_at DESC LIMIT 20，看着没问题，但一旦加了分类筛选或标签筛选，
created_at索引就失效了——因为 MySQL 无法同时高效使用
WHERE category_id = ?和
ORDER BY created_at的复合排序。
正确做法是建联合索引：
CREATE INDEX idx_cat_status_time ON kb_article (category_id, status, created_at);
这样查某分类下最新 20 篇已发布文章才快。如果还要支持按标签查，就得另建索引：
CREATE INDEX idx_tag_status_time ON kb_article_tag (tag_id, status, created_at);
注意：
kb_article_tag表本身没
status字段，得把它和
kb_articleJOIN 后再 WHERE 过滤，所以这个索引要包含
status才能走索引下推（ICP）。
备份与字符集必须设对，否则中文变问号
新建库时如果漏掉字符集声明，或者用默认
latin1，后面所有
INSERT中文都会变成
???，且无法恢复。不是改表字符集就能修好，历史数据已损坏。
初始化命令必须带参数：
CREATE DATABASE kb_system CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
然后每张表建表语句末尾都显式指定：
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
另外，mysqldump 备份时务必加这两个参数：
--default-character-set=utf8mb4
--skip-set-charset（避免 dump 文件里硬编码
SET NAMES latin1）
utf8mb4 是底线，别信“utf8 就够用”——emoji、生僻汉字、数学符号全靠它。一个字节差，整库检索就崩。
