1. 课程导论：为什么需要事务连接池水位审计基线？
1.1 从一次“雪崩”事故说起
某金融核心系统在业务高峰时段，因上游流量瞬时激增，数据库连接池被全部占满。新请求排队等待连接，超时后不断重试，导致连接池压力持续攀升。最终数据库负载过高，触发熔断，核心链路中断 12 分钟。事后排查发现：连接池水位长期处于 85% 以上，但从未触发告警——因为团队只监控了“连接池是否满”，而没有建立“水位基线”与“事务行为”的关联审计。
关键教训： 连接池满只是结果，水位异常升高才是前兆。没有基线，就无法区分“正常业务波动”与“连接泄漏/事务慢查询”。
1.2 核心概念：事务连接池水位审计基线
| 概念 | 定义 | 在 Go 中的典型表现 |
|---|---|---|
| 连接池水位 | 当前活跃连接数占最大连接数的百分比 | stats.InUse / stats.MaxOpen |
| 事务水位 | 处于事务中的连接占活跃连接的比例 | stats.InTx / stats.InUse |
| 审计基线 | 基于历史数据建立的正常水位波动区间 | P50/P95/P99 水位阈值 + 事务持续时间分布 |
| 水位审计 | 实时水位与基线对比，识别异常偏离 | Prometheus 告警规则 + 日志采样 |
1.3 为什么需要水位审计基线？
- 提前发现连接泄漏 —— 事务结束后未归还连接，水位持续上升不回落。
- 识别慢事务 —— 单个事务占用连接超过基线 P99 时长，阻塞其他请求。
- 区分正常毛刺与异常尖峰 —— 秒杀活动水位 90% 持续 5 秒是正常；非活动期水位 90% 持续 30 秒是异常。
- 指导连接池容量规划 —— 基线数据帮助确定
MaxOpen、MaxIdle、ConnMaxLifetime的合理值。 - 支撑 SLO 与容量模型 —— 将水位指标纳入服务等级目标，量化系统健康度。
实践建议： 在 Go 项目中，使用
database/sql 包的 DB.Stats() 方法每 10 秒采集一次连接池指标，持续 7 天即可建立初步基线。
1.4 水位审计的核心流程
1.5 课程目标与学习路径
完成本课程后，你将能够：
- 掌握 Go 连接池内部模型 ——
database/sql的连接生命周期、事务绑定机制、Conn与Tx的关系。 - 设计水位审计基线 —— 基于 Prometheus + Grafana 采集
DB.Stats()指标，计算 P50/P95/P99 水位阈值。 - 实现实时水位告警 —— 编写 PromQL 告警规则，区分“连接池满”与“水位异常升高”。
- 排查典型水位异常 —— 连接泄漏、事务超时未提交、慢查询阻塞、连接池饥饿。
- 输出审计报告 —— 将水位基线纳入日常巡检与容量规划文档。
前置要求： 熟悉 Go 基础语法、
database/sql 基本用法、Prometheus 指标采集概念。本课程不讲解基础 SQL 或 Go 入门。