2024 年春天，我在整理 DAL 小组的工作总结。从 2021 年 11 月到这个时候，两年半的时间，这个小组从零搭起了一套数据库治理体系。这篇算是个复盘，把”怎么搭起来的”这个脉络理清楚，给后来人留个参考，也给自己留个记号。

起点：一团乱麻

2021 年底我刚进 DAL 小组的时候，公司的数据库访问状况可以用四个字形容：各自为战。

  • 十几个 Java 服务，连接池配置五花八门，有的用 HikariCP，有的用老掉牙的 c3p0，有的干脆裸连。
  • Python 服务更乱，有的用 SQLAlchemy，有的用 pymysql 直接连。
  • 没有统一的慢查询监控。出了问题靠用户投诉和 DBA 看 processlist。
  • DDL 变更没有审核流程，谁想改就改，好几次差点出大事。
  • 多租户隔离靠业务代码自觉，数据串号的隐患一直悬着。

那时候谈不上治理，全是救火。再不抓就要出大事。

搭体系的顺序

回顾这两年半，我们做的事其实有一个清晰的顺序。这个顺序是 dependencies 决定的。

第一步：变更审核（地基）

时间：2021 年底到 2022 年初。

理由很简单：变更不停，事故不止。不先把变更审核流程建起来，SDK 做得再好也白搭，因为一个 ALTER TABLE 就能把线上搞挂。

具体怎么做，前面那篇《DAL 小组：数据库变更审核怎么做》讲过了。核心就是工单 + 评审会 + 执行复核。

先止血，再治病。这是体系搭建的铁律。

第二步：Java SDK（主力收口）

时间：2022 年上半年。

变更审核把”乱改”的问题摁住了，接下来要解决”乱连”的问题。

先做 Java 版，因为 Java 是主力语言。HikariCP 做连接池，自研读写分离，慢查询自动上报。半年时间，十几个 Java 服务全部接入了 dal-java SDK。

这一步的价值是让基础设施的升级能一次推到所有服务。以前改个连接池参数得求着十几个团队，现在改 SDK 配置中心一处，全部生效。

第三步：Python SDK（覆盖长尾）

时间：2022 年下半年。

Java 收口之后，Python 那边的”裸连”就显得特别扎眼。Python 服务虽然少，但数据访问的诉求一样：连接池、读写分离、慢查询监控。

用 SQLAlchemy 独立搭建，行为和 Java 版对齐。难点不在写代码，在保证两端的行为契约一致：同样的读写分离规则、同样的慢查询阈值、同样的配置来源。

第四步：慢查询治理（持续运动）

时间：2023 年全年，一直延续。

SDK 把慢查询采集和上报建好之后，剩下的就是”持续优化”的活。每周从 Top 慢查询里挑几条出来，EXPLAIN 分析，加索引、改 SQL。

这件事没什么技巧，就是持之以恒。做了半年之后，线上 P99 慢查询数量降了一个数量级。

第五步：多租户隔离固化（查漏补缺）

时间：2023 年中。

多租户隔离方案从系统早期就存在，但原来靠业务自觉。DAL 小组把它下沉到 SDK 层：自动注入 tenant_id，不设上下文就报错。把”约定”升级成”强制”。

第六步：分库分表调研（论证）

时间：2023 年下半年。

业务量涨上来之后，”要不要分库分表”的问题被反复问。我们花了半年做调研和试点，最后结论是不上中间件，靠优化 + 读写分离 + 缓存扛住。这个决策的逻辑前面那篇讲过了。

体系的脉络

把上面六步串起来，就是这套数据库治理体系的脉络：

1
2
3
4
5
6
7
8
9
10
11
12
13
变更审核（止血）
    ↓
Java SDK（主力收口）
    ↓
Python SDK（覆盖长尾）
    ↓
读写分离 + 慢查询监控（SDK 内建能力）
    ↓
慢查询治理（持续运动）
    ↓
多租户隔离固化（查漏补缺）
    ↓
分库分表调研（论证边界）

体系不是一天建成的，是一层一层叠上去的。每一步都为下一步铺路。

哪些做对了

回头看，有几个决策我觉得是对的：

  1. 先做变更审核，再做 SDK。如果反过来，SDK 还没做完，线上已经被乱改的 DDL 搞挂了。

  2. Java 先做，Python 后做。先把主力语言收口，趟一遍雷，再做 Python。顺序清楚，风险可控。

  3. 读写分离自研，不上中间件。省了运维成本，避免了单点风险，Python 也能用同一套逻辑。

  4. 没上分库分表。这是最容易被质疑的决策，但事后看是对的。复杂度债务能不借就不借。

哪些可以做得更好

也有遗憾：

  1. Python 版动手太晚。Java 版做完后拖了大半年才动 Python。中间那段时间 Python 服务还在裸连，等于多冒了半年的险。理想情况应该 Java 版稳定后就立刻铺 Python。

  2. 慢查询治理断断续续。中间有段时间大家忙别的，Top 慢查询的优化停了两周。慢查询积了二十多条，花了一个月才清完。持续运动这件事，停下来再启动成本很高。

  3. 监控告警阈值不精细。一开始慢查询阈值统一设 200ms，后来发现不同业务该有不同的阈值。精细化调整做晚了。

体系的本质

做了这两年半，我对”体系”这个词的理解变了。

以前觉得体系就是一堆工具和流程的集合。现在我觉得，体系的本质是”让正确的事情变容易，让错误的事情变困难”。

  • 变更审核：让”乱改 DDL”变困难。
  • SDK 收口：让”乱连数据库”变困难。
  • 多租户隔离下沉：让”漏带 tenant_id”变困难。
  • 慢查询监控：让”忽略性能问题”变困难。

好的体系靠机制拦住错误，不靠人盯。

人盯会累、会忘、会换岗。机制不会。一个团队的人会流动，但体系留下来，新来的人照着走就行。

写在最后

DAL 小组的这套体系不算先进，没有什么原创架构，都是业内成熟方案的组合。但它的价值在于完整和持续：从变更到 SDK 到监控到治理，一条线走下来，没有断层。

技术体系的价值不在单点的牛逼，在整体的协同。

两年半，从一团乱麻到一套能跑的体系。这个过程让我学到的东西，比任何一本书都多。