Insidedb

一句话定位

一个把数据库内部原理做成可交互动画的网页——插入一个键，看 B 树怎么分裂；拔掉电源，看 WAL 怎么把数据救回来。用"玩"替代"读"，讲清楚 B 树、查询计划、预写日志和 MVCC 四个主题。

做这个东西的人

作者 GitHub 账号 david-g-3654（David G.），个人项目，托管在 GitHub Pages 上，仓库创建于 2026-08-11，与 HN 发帖同日。团队背景、动机未披露。

判断：这是典型的"讲不清不如做出来"型作品。作者大概率是被"怎么跟人解释数据库"逼出来的——因为静态图解释不清，才做了动画。

它到底能做哪几件事

• B 树 → 插入键时实时看节点分裂、中间键上移，能看到树高与"找到任意键的读取次数"
• 查询计划器 → 同一个 WHERE 跑两种计划（全表扫描 vs 走索引），直观对比 cost 估算怎么选
• 预写日志 → 一步步把写入、提交、拔电、恢复的时序演给你看
• MVCC → 读与写互不阻塞的版本化机制

每个主题都是一段可操作的动画，不是静态图解。

它在替代什么旧行为

以前学数据库内部原理，靠三样东西：教科书（静态图）、博客长文（ASCII 图和文字描述）、以及别人录的教学视频（只能看不能动）。

这个页面把"读图+脑补"换成"亲手操作"：你自己插入键、自己拔电源、自己换查询计划。对"搞懂"这件事，可交互解释器比文字快得多——但它只覆盖了四个主题，没有系统性课程结构，替代的是"查一个知识点"的动作，不是"学一门课"。

商业模式

无。纯免费教育页面，无广告、无付费、无课程衍生。

判断：这类单页解释器通常是为了名气或求职作品集，而不是生意。它的商业价值在于证明作者能把复杂系统讲明白——这是能被招聘市场定价的能力。

硬数字

• HN 5 分 / 0 条评论
• GitHub 仓库 0 star / 0 fork，创建于 2026-08-11
• 覆盖 4 个主题：B 树、查询计划、WAL、MVCC
• 团队、作者全名、任何商业化计划：未披露

四维评估

判断

形式判断正确，但样本太小。 交互式解释器对"复杂系统怎么运转"这类知识几乎总是比文字更有效，这个方向没有疑问。问题是它只有四个主题、没有增长数据，也没有任何转化为产品/课程的迹象。

判断：这类项目真正值得跟踪的不是这个页面本身，而是它代表的一类内容形态——把系统原理做成可玩的东西。这类内容正在从"教学辅助"变成"产品形态"本身。

下一步看什么

① 主题数是否从 4 个继续增长——停在 4 个就是一次性作品，持续更新才谈得上产品 ② GitHub stars 三个月后是否破百 ③ 作者是否把它扩展成课程/付费内容，或至少公开后续计划

可借鉴的做法

内容逻辑：讲任何"过程型"知识（协议、算法、系统机制），先问一句"这个能不能让读者亲手操作一步"。能把"看"变成"做"，理解成本下降一个数量级，而且作品本身自带传播性——录屏比文字摘录好传播。

工程取舍：单页面、无依赖、GitHub Pages 免费托管，把一个知识点做到极致，而不是堆主题。对个人内容产品，这是成本最低的启动方式。

结论

有待观察。 形式对、执行好，但既没有产品意图也没有数据。记下来作为"交互式解释器"这个内容形态的参考样本，三个月后看它有没有长成别的东西。