每天输出一篇数据库实战之后，我发现了自己的三个瓶颈
每天输出一篇数据库实战之后，我发现了自己的三个瓶颈
两个月前的一次组会上，Leader 突然问我：“你最近写了不少 MySQL 和 Doris 的文章，那你说说，如果现在让你从零设计一个存储引擎，你会怎么考虑？”
我愣住了。脑子里全是 Buffer Pool 的脏页刷新策略、Doris 的 Compaction 触发阈值、索引下推的执行流程——但这些碎片化细节像一堆散落在地上的乐高积木，我无法在短时间内拼出一个完整的结构。最后我只能含糊地说：“这个问题我需要再整理一下。”
那天晚上我没有继续写新的文章，而是打开了自己的博客目录，一篇一篇翻过去。四十七篇实战文章，从 MySQL 慢查询分析到 Doris 分区分桶策略，每一篇单独看似乎都“有点东西”。但当我跳出来审视这些内容时，一个不舒服的发现浮了上来：我好像一直在做知识的搬运工，而不是知识的建筑师。
三个瓶颈浮现
连续输出带来的第一个幻觉是“我在变强”。文章一篇篇发出去，阅读量、点赞、收藏这些正反馈会强化这个感觉。但正反馈本质上是一个危险的信号——它告诉你“这条路走对了”，却不会告诉你“这条路通向哪里”。当我把四十七篇文章的标题全部列在表格里时，我发现自己一直在几个熟悉的话题里打转：慢查询优化、索引失效案例分析、参数调优记录。每一篇都是真的，每一篇都有实战基础，但合在一起，它们的边界并没有拓宽多少。
这就是第一个瓶颈：重细节轻全局。我熟悉一棵树的每一片叶子，却回答不出这棵树长在什么样的森林里。比如我写过三篇关于 Doris 数据模型（Duplicate/Aggregate/Unique）的文章，但如果有人问我“这三种模型在存储层和计算层分别做了什么取舍，这种取舍的根源是什么”，我的回答会变得模糊。细节的堆积不会自动上升为全局认知，它只是让你在熟悉的领域里越来越熟练而已。
第二个瓶颈藏得更深，是重实战轻原理。实战文章天然受欢迎，因为读者可以直接抄作业。而写作者也容易沉浸在这种“被需要”的感觉里——你解决了一个具体的问题，读者表达了感谢，一切都很美好。但问题在于，如果你只解决具体问题，你就永远停留在“经验”层面，而经验是不可迁移的。今天你解决了 MySQL 的一个死锁问题，如果明天遇到 Doris 的锁竞争问题，你并不会因为前者而自动理解后者，除非你从两者中抽象出更底层的原理。
我翻到自己写的一篇关于“Doris 查询超时排查”的文章，通篇记录了我怎么发现是某个 Tablet 的 Rowset 数量过多导致的读放大。看完之后我意识到，文章里只有“是什么”和“怎么解决”，却没有“为什么会这样设计”“如果不这样设计会怎样”“类似的取舍还出现在哪里”。一旦条件改变，这篇文章的价值就归零了。
第三个瓶颈是重完成轻消化。每天输出一篇的节奏，意味着我必须在有限时间内完成“找题目—写正文—发布”的流水线。这个流水线高效运转之后，它自身的惯性就会推着你往前走。很多时候我还没真正消化一个知识点，就已经开始写下一篇了。写作成了表演性的输出——内容是真的，但理解是浅的，验证是靠运气碰上的，真正的内化从未发生。
这个瓶颈最容易自我欺骗，因为它有一个完美的辩护词：“我在实践中学习”。但实践学习的前提是反馈闭环，而不是单方向的输出。如果写完文章之后没有一个“这篇东西我到底懂了多少”的检验机制，那输出就只是一场精心包装的输入复制。
输出倒逼输入，但输入不能变成表演
这三个瓶颈本质上是一件事：我把“持续输出”这个手段当成了目的。输出倒逼输入，这个逻辑是成立的——如果你不持续学习，你就没有新内容可写。但这里有一个微妙的陷阱：当你开始为了输出而输入时，输入的质量会下降。你会倾向于选择那些“容易写成文章”的内容，而不是“真正需要搞懂”的内容；你会倾向于把理解停留在“能解释清楚”的程度，而不是去追问“为什么这样设计”“有没有更好的方式”。
说白了，就是让输入变成了一场表演。观众以为你在深入学习，其实你在为下一篇文章找素材。
我花了一周时间停下来，重新审视自己的知识结构。我画了一张关于“数据库内核”的粗略图谱，在缓存管理、存储引擎、查询优化、并发控制这几个大方向上分别标出自己“能说清楚原理”“只能说个大概”“完全不懂”的区域。结果很残酷：我的能力分布和我的文章分布高度重合，全都在最热门的查询优化和实战调优区域，而存储引擎的底层实现、事务隔离的完整推导、优化器的算法细节，几乎全是空白。
这张图成了我的新起点。
三个可以立即开始的动作
我没有放弃写作，但改变了写作的方式。这里有三件事我觉得值得分享：
第一，每周做一次深度复盘，而不是只统计产出。 每周五下午我会花四十分钟，把那周写过的文章重新看一遍，然后问自己三个问题：这篇文章覆盖的知识点，我能不能脱稿讲清楚它的“为什么”？这篇文章涉及的内容，如果场景变了，我还能不能找到解决路径？这篇文章和之前的内容有没有形成联系，还是依旧是一个孤立的点？如果三个问题里有两个回答“不能”，下周的选题优先级就会被降低，让位给查漏补缺。
第二，用知识图谱而不是文章列表来驱动学习。 文章列表是线性的，它会诱导你往下写而不是往上建。知识图谱是结构化的，它会暴露你的空白区域。我现在的做法是先把一个领域的骨干搭出来——比如数据库内核的四个大方向——然后每写一篇文章，都要在地图上标注它的位置，并检查这篇文章有没有和已有的节点产生连接。如果一篇文章在地图上是一个孤岛，那它很可能只是在堆细节。
第三，主动写自己不擅长的内容。 这是最反人性但最有效的一条。当你写了一篇非常顺手的文章时，那种流畅感不是能力的证明，而是舒适区的信号。我会定期选择一些自己写起来很费劲的题目，比如一篇尝试讲清楚 Doris 的存储模型和 LSM-Tree 之间关系的文章，写了三版都觉得没讲透，但写的过程本身就是对理解的最大推动。输出不再是为了证明“我懂了”，而是为了暴露“我还没懂”。
两个月后再回到那个组会的场景，我知道我对“从零设计存储引擎”这个问题依然没有完美的答案。但不同的是，现在我知道自己缺什么了。这不是一个更愉快的状态，但却是一个更清醒的状态。
写作的陷阱从来不是写得不够多，而是写得太顺。当你每天都能轻轻松松地输出时，就是最该警惕的时候。
本文由 Claude（Anthropic）辅助生成。验证日期：2026-08-18。