CacheSQL（一）：手写数据库的工程化重生
写过一套 2000 行的 B+ 树手写数据库，当时觉得"能跑了"。放了一阵子回头看，发现能跑和能交付之间隔了十万八千里。
CacheSQL 就是这段回头路走出来的。同一个 B+ 树内核，但外面长了三层新东西：复制、HTTP、测试。从原型变成了产品。
一、原型长什么样
这是手写数据库那版的核心结构：
com.bluepointsoft.database
├── database.java # 数据库入口，HashMap 管理表
├── praseSql.java # SQL 解析
├── btree/
│ ├── BPTree.java # B+ 树封装
│ ├── Node.java # B+ 树节点（核心，1054 行）
│ └── Tree.java
├── table/
│ ├── Table.java # 内存表
│ ├── Row.java # 行数据（软删除）
│ └── rowSet.java # 行集合
├── container/myList.java # 自定义 long[] 数组
└── fun/function.java # SQL 函数桩这个版本解决了核心问题------B+ 树的插入、分裂、删除、合并、范围查询------但有几个硬伤：
- 没有测试。 能跑，但不知道什么情况下会崩。
- database 类用
ConcurrentHashMap是原型遗留思维。 手写数据库那版我开始用 HashMap，后来多线程冲突才换成 ConcurrentHashMap，但当时没有真正理解这意味着什么------不是锁的问题，是一个项目需要从"跑的 Demo"切换到"可交付产品"。 - SQL 解析是散装函数，不是引擎。
praseSql.select_items(sql)、praseSql.select_table(sql)、praseSql.select_where(sql)------每次查都要调三个静态方法，各自解析一次 SQL。 - 没有对外 API。 只能内嵌调用 Java，没 HTTP 接口，其他语言用不了。
- 没有文档。 别人不知道这玩意怎么用。
二、工程化重生的五个改动
2.1 项目结构从平铺到分层
com.browise.database
├── database.java # 表管理 + 定时刷新
├── SqlQueryEngine.java # SQL 引擎（独立模块）
├── btree/ # B+ 树（核心不变）
├── table/ # Table/Row/rowSet（核心不变）
├── index/CompositeKey.java # 新增：联合索引
├── server/ # 新增：HTTP 服务层
├── replication/ # 新增：主从复制
├── core/util/DBUtil.java # 新增：连接池 + 配置管理
└── core/exception/utilException.java # 新增：统一异常核心层（btree + table）基本没动。新东西全加在外面，核心层连复制都不知道------ReplicationManager 对 Table 和 BPTree 完全透明。
2.2 从 HashMap 到 ConcurrentHashMap
手写数据库那版，database.java 用的是 HashMap<String, Table>。AI 审计时指出的第一个问题是"线程不安全"------两个线程同时 load 同一张表会互相覆盖。我换成 ConcurrentHashMap 时，没多想。后来才意识到这个切换意味着什么：
HashMap → ConcurrentHashMap 这个决策本身是"产品意识"的起点------你开始假设这个系统会被并发调用，而不是只在你自己的电脑上跑一个线程。
CacheSQL 里更进一步。tables.putIfAbsent 替代了 tables.put，防止并发 load 时创建重复 Table。refresh 时用 tables.put(name, fresh) 原子替换------先创建新 Table 实例加载最新数据，完成后再替换引用，刷新期间的查询不受影响。
2.3 SQL 解析从散装函数到独立引擎
手写数据库那版 SQL 解析是三个静态函数：
java
List<String> items = praseSql.select_items(sql);
List<String> tables = praseSql.select_table(sql);
String where = praseSql.select_where(sql);CacheSQL 拆出了独立的 SqlQueryEngine：SQL 模板化 → 解析 → 缓存执行计划 → 下次同模板直接复用，省掉重复解析。这个设计让后续加 HTTP 接口时天然就支持了 SQL 查询------不需要单独实现一套查询逻辑。
2.4 从零测试到 53 项测试 + 6 项集成
手写数据库那版没有任何测试用例。CacheSQL 加了两层测试：
- 53 项单元测试：B+ 树 15 项，SQL 引擎 11 项，内存表 17 项，复制模块 8 项，并发 2 项
- 6 项集成测试：端到端验证主从复制的完整生命周期------写入广播、Slave 转发、幂等性、Master 宕机缓冲、恢复后自动重放
不是说测试越多越好。但一个没有测试的产品，你不敢交付给任何人。
2.5 从零文档到 7 份
功能说明书、部署手册、操作手册、测试报告、性能测试、两版审计报告。加上已有的 4 篇手写数据库博客------这些文档不是给评委看的，是给未来任何一个接手这个系统的人看的。
三、什么没变
B+ 树核心逻辑几乎没变。
- 256 阶：和原型一样，一次加载 256 个子节点，树高度为 2（100万数据）
- 软删除 ：原型里的
isDelete标记保留，仍是 O(1)，不移动 ArrayList 元素 - 预留空间：原型里 10% 的预留设计保留，批量插入时减少分裂频率
- 关键字校准 validate：原型里那个踩了大坑的函数保留------分裂后父节点的 entry key 不更新就会路由出错
不是什么都要重写。核心对了，外围加工程化就好。
四、AI 在这个过程中的角色
手写数据库 4 篇博客提到的 B+ 树算法（分裂、借位合并、二分变体、validate 校准），有一些是我自己写的（软删除、预留都是我的经验），有一些是 AI 辅助生成的（代码框架、文档结构）。
CacheSQL 的工程化升级，AI 承担了大部分"写代码"的工作：项目结构、测试用例、文档框架、异常处理、配置文件解析。我承担的是架构决策：ReplicationManager 对核心层透明、OpLog 用定长环形缓冲区而非 ArrayList、insert 用 upsert 语义保证幂等------这些没有一个是 AI 主动建议的。
用 AI 写代码，用经验做决策。 这就是从原型到产品之间，AI 和人的分工。
系列：CacheSQL 工程化交付实录（共 5 篇，含桥接篇）