桥接篇从练手到交付——四篇博客之后我回头做了 CacheSQL先写了一个 2000 行的手写数据库又写了四篇博客来记录它。写完那一刻觉得差不多了。回头一看发现差远了。不是代码差——是练手项目和可交付产品之间的鸿沟。跨越这道鸿沟的过程成了 CacheSQL。一、什么留下了B 树内核。256 阶、叶子双向链表、分裂传播、借位合并、二分变体 searchless/searchmore——核心算法全留了。这些是原型里最对的东西。算法上验证过的不需要重写。保留内核、外面套工程化层是最高效的方式。两个设计也留下了软删除。Row 的isDelete标记O(1) 完成不移动 ArrayList。手写数据库那篇里讲过这是删了真删的坑才改的——删了 data.remove(i)后续元素下标全变B 树存的地址全乱。CacheSQL 里这个设计没变而且更成熟了配合compact()定期回收已删除行解决了一直软删会占满内存的问题。预留空间。节点不填满再分裂而是 90% 容量时提前分。这个设计在手写数据库的博客里有详细解释——减少后续插入的分裂频率。CacheSQL 里保留了这个策略因为它确实生效。二、什么加了测试手写数据库那版没有任何测试用例。CacheSQL 加入了 53 项单元测试和 6 项集成测试。不是说加了就高级了——是交付的定义变了不是你跑通了是别人跑通过了你也安心。复制原型只有单机。加上了主从复制——ReplicationManager、OpLog、SyncClient、SyncServer。设计原则是核心层零修改Table 和 BPTree 不知道复制的存在。OpLog 的设计考虑了三个边界容量固定环形缓冲区不无限增长、序列号递增Slave 离线可检测覆盖、upsert 语义pendingQueue 重放安全。HTTP原型只能 Java 调用。加上了 HTTP两套引擎JDK 内置和 Undertow NIO。通过HttpServerEngine接口隔离配置文件切换。不是为了花哨。是为了让运维脚本、Python 工具、其他服务能查到缓存数据。文档原型没有任何文档——代码就是文档。CacheSQL 写了 7 份功能说明书、部署手册、操作手册、测试报告、性能测试、两版审计报告。加上已有的 4 篇手写数据库博客形成了完整的技术资产。SQL 引擎原型里 SQL 解析是三个静态函数。CacheSQL 拆出了独立的SqlQueryEngine加了执行计划缓存和模板化机制相同 SQL 模板只解析一次。这是从能解析到高效解析的关键一步。三、两套博客的关系手写数据库 4 篇博客是B 树算法教程。内容密集、有代码片段、有踩坑分析。适合想学 B 树的读者——可以跟着写一遍理解核心数据结构。CacheSQL 3 篇是架构工程实录。内容关于工程决策、抽象设计、取舍权衡。适合做架构的人——看怎么把一个原型包装成产品。两套博客之间有一个真实的时间线写原型 → 写博客 → 发现不够好 → 做工程化升级 → 再写博客。第一套是学会第二套是做好。这就是从练手到交付的真实路径。四、关于 AI 辅助两套博客和两个项目全程 AI 辅助。算法细节的修正——软删除、预留空间——是我在踩坑中自己的总结。代码框架、测试用例、文档结构是 AI 出力的。架构决策——ReplicationManager 透明化、OpLog 环形缓冲、upsert 幂等语义——是我做架构多年积累的经验判断。AI 帮我写代码但不会主动说这里的写操作需要幂等性保证。这个判断来自你对Master 宕机后 Slave 重连可能重复操作的预判。用 AI 写代码用经验做决策。这是整个 CacheSQL 项目中人与 AI 分工的真实写照。也正是我给同事们讲的AI 提效方法论的核心——你的价值在决策不在执行。系列CacheSQL 工程化交付实录共 5 篇含桥接篇手写数据库系列[一起因与架构二B树的插入与分裂]三删除合并与范围查询]四索引引擎、SQL解析与总结]CacheSQL 项目CacheSQL一工程化重生CacheSQL二主从复制CacheSQL三双引擎与SQL查询CacheSQL四水平扩展