标签云系统必须用三张表，不能只靠 articles 表加 tags 字段
把标签硬编码进 articles 表的 tags 字段，比如存成逗号分隔的字符串，这招看起来省事，实则后患无穷。这么一来，查询、统计、去重这些核心功能基本就瘫痪了。你想想，怎么高效地找出同时打上了「MySQL」和「性能优化」两个标签的文章？又怎么快速统计出哪个标签最受青睐？几乎无从下手。
所以，标准答案永远是拆成三张表：articles、tags，以及负责关联的 article_tags（也就是中间表）。中间表结构极简，两个字段足矣：article_id 和 tag_id。别忘了给它加上联合主键或者唯一索引，这是防止数据重复的关键。
查标签云数据时，别直接 GROUP BY tag_name，先 JOIN 再 COUNT
这里有个经典的性能陷阱。如果标签名称存在 tags 表的 name 字段里，而中间表只存 ID，那么统计标签使用次数就绕不开 JOIN 操作。常见的错误做法是：先查出所有标签列表，然后在应用层循环查询每个标签的计数。结果就是著名的“N+1查询”问题，标签数量一上百，数据库立马就吃不消了。
正确的姿势，是用一条 SQL 搞定：
SELECT t.name, COUNT(at.article_id) AS cnt
FROM tags t
LEFT JOIN article_tags at ON t.id = at.tag_id
GROUP BY t.id, t.name
ORDER BY cnt DESC
LIMIT 50;
这里有两个细节值得玩味：第一，使用 LEFT JOIN 是为了确保那些还没被任何文章使用过的标签（比如一些预置标签）也能被统计进来，当然，这取决于你的业务需求。第二，GROUP BY 子句里必须同时包含 t.id 和 t.name，尤其是在 MySQL 8.0 以上的严格模式下，只按 name 分组是会直接报错的。
中间表没加索引？查得慢、删标签还锁表
article_tags 这张表结构简单，但千万别小看它，索引没加对，分分钟变成性能黑洞。很多人以为有了联合主键 (article_id, tag_id) 就万事大吉，其实不然。这个主键索引无法高效支撑“查找某个标签下的所有文章”，或者“删除某篇文章的所有标签关联”这类反向查询。
因此，至少需要补上下面两个索引：
INDEX idx_tag_id (tag_id)：这个索引是“按标签查文章”和“统计标签热度”的翻跟斗。INDEX idx_article_id (article_id)：这个索引则专门优化“删除文章标签”和“查看文章标签”的操作。
索引缺失的后果很直接。举个例子，当你执行 DELETE FROM article_tags WHERE tag_id = ? 来删除一个标签的所有关联时，数据库如果只能进行全表扫描，在数据量大的情况下，很可能导致中间表被锁住好几秒，整个系统的写入都会受影响。
标签名重复怎么办？用唯一约束 + INSERT IGNORE 而不是 SELECT 判断
用户输入“mysql”、“MySQL”、“MYSQL”，明明指的是同一个东西，但数据库里却可能躺着三条记录。解决这个问题，靠应用层代码反复查询去重是下策，把责任交给数据库的约束机制才是上策。
可以在 tags 表上建立一个基于小写的唯一索引：
UNIQUE INDEX uk_name_lower (LOWER(name))
这样一来，插入新标签时，直接用：
INSERT IGNORE INTO tags (name) VALUES ('MySQL');
所有大小写变体都会自动被去重。需要注意的是，LOWER(name) 这种函数索引在 MySQL 5.7+ 版本才被良好支持，8.0+ 更稳定。如果是 5.6 或更早的版本，可能需要增加一个存储小写名称的计算列，或者在应用层统一转成小写后再插入。
最后，还有一个容易被忽略的“家务事”——中间表的生命周期管理。时间长了，tags 表里难免会积累一些“孤立标签”，也就是那些在 article_tags 表里没有任何关联记录的标签。这些数据幽灵多了，标签云里就会出现一堆没人用的“僵尸标签”。要不要定期清理？这得看业务逻辑。如果业务允许存在“预置标签”（即先创建好，等待文章使用），那么就不能简单地根据是否存在关联来判断是否删除，可能需要在 tags 表里增加一个状态标记字段来区分。
