这次升级的直接原因是，昨天下午三点，后台监控突然报警，查询延迟从平均 30ms 飙到了 800ms 以上。我盯着 Grafana 的曲线图，脑子里第一个念头不是技术问题，是“又他妈来了”。这种毫无征兆的性能雪崩，在 2019 年带团队做外包项目时几乎每周上演，服务器像定时炸弹，客户催命，团队熬夜，最后发现就是个索引没建对。历史总是换着花样重演，只是这次炸弹埋在我自己的 IP 项目里。
我切到数据库终端，SHOW PROCESSLIST 一拉，满屏的 “Sending data” 状态，锁在几张核心表上。问题出在“文章-标签”的多对多关联查询上。早期的设计太 naive 了，直接 articles 表、tags 表加一个 article_tag 关联表，看起来标准。当文章积累到三千多篇，标签总数破万，单篇文章平均挂 5-6 个标签时，任何带标签过滤的复杂查询（比如“找出同时有‘AI自动化’和‘n8n’标签，且发布于 2024 年后的所有文章，按阅读量排序”）都会变成 JOIN 地狱。MySQL 的查询优化器在这种多表 JOIN 且带有范围查询和排序时，很容易选错执行计划，直接拉垮。
这让我想起 2017 年做 SEO 站群的时候，也是死磕数据库。那时候用 Python 爬虫灌数据，一晚上几百万条记录往 MySQL 里插，然后疯狂建索引，试图让模糊查询快一点。结果索引文件比数据文件还大，一个 ALTER TABLE 能锁表半小时。当时觉得是硬件不行，拼命加内存加 SSD。现在看，根子上是结构问题。技术债这玩意儿，你当年偷的懒，会在未来某个毫无准备的下午，用最粗暴的方式让你连本带利还回去。
所以这次升级，我没选择在原有结构上打补丁（比如再加一层 Redis 缓存），那只是把问题往后推。我决定重构底层。新设计的核心就一条：用空间换时间，并且把最频繁、最复杂的查询路径“拍平”。具体来说，我彻底放弃了纯关系型的范式约束，引入了适合文档检索的混合结构。
主表 `articles` 核心字段没大动，但增加了几个关键冗余字段：`tag_ids`（JSON 数组，存储关联标签的 ID 列表）、`tag_names`（JSON 数组，存储关联标签的名称快照）。这违反了第三范式，但好处是，80% 的标签过滤查询，现在不需要去关联 `article_tag` 和 `tags` 表了，直接在 `articles` 表里用 JSON_CONTAINS 函数就能搞定。虽然函数查询也有开销，但比多表 JOIN 和多次回表要轻量得多。`tag_names` 的快照是为了避免在列表页显示时还要去查标签表取名字。
然后，我新建了一个 `article_tag_denormalized` 表。这就是个彻底的“宽表”，每一行代表一篇文章和一个标签的组合，但把文章的核心信息（标题、发布时间、摘要、阅读量）全部冗余存储进来。这张表专门用来服务那些需要按标签聚合、排序、分页的复杂查询场景。比如后台的“标签管理”页面，要统计每个标签下有多少文章、最新文章是哪篇，现在一个简单的 SELECT tag_id, COUNT(*), MAX(publish_time) FROM article_tag_denormalized GROUP BY tag_id 就解决了，速度快得不像话。这张表通过异步任务来维护一致性，文章更新时，触发一个消息队列任务去重建这条文章在所有标签下的冗余记录。
最后是全文搜索。之前用的 MySQL 的 FULLTEXT 索引，中文分词是个残废。这次直接集成了 MeiliSearch，把文章标题、正文纯文本、标签名称扔进去。`articles` 表里加了个 `search_indexed_at` 的 timestamp，用来标记是否需要同步到搜索引擎。查询时，前端直接请求 MeiliSearch 的 API，彻底解放了数据库的压力。
整个迁移过程，我用 n8n 写了个工作流，把旧数据分批读取、转换、写入新结构，同时对比校验。这活儿要是放在 2019 年，得让手下的小孩干好几天，还容易出错。现在一个可视化工作流，配置好节点，泡杯咖啡的功夫就跑完了。这就是“超级个体”工具链的威力，也是我这两年死磕 AI 和自动化的原因——你不是在学一个玩具，是在给自己装配工业级的生产力杠杆。
架构的承载力，从来不只是技术指标。它承载的是你未来业务变化的可能性，是你深夜被报警吵醒时的心脏负荷，更是你作为构建者，是选择不断在破房子上打补丁，还是咬牙推倒重来一次的那点心气。这次我选了后者。虽然接下来几天可能还要处理一些边角料的兼容性问题，但我知道，至少在未来一年内，当我想快速试验一个新的内容聚合功能时，底层不会再给我使绊子了。
这博客，这个从 2016 年一堆爬虫脚本和 SEO 关键词里长出来的东西，终于有了一个配得上 2025 年 Flovico 这个身份的底盘。
