数据库

背景与问题界定 周一早晨的告警群突然被MySQL连接数报警刷屏——某订单服务的数据库连接数在30分钟内从200飙升至3000，直接触发数据库端的max_connections限制，导致新建连接全部被拒绝。紧急重启服务后连接数恢复正常，但连接数再次以每分钟50个的速度持续增长。通过netstat排查发现大量TIME_WAIT状态的连接未被复用，数据库连接池的活跃连接远低于已建立连接数。 这是典型的连接泄漏场景。Go的database/sql包维护了一个自动的连接池，理论上可以复用连接，但在实际场景中，事务未提交或回滚、context超时后连接未正确归还、长事务占用连接不释放、第三方库对连接的生命周期管理不当等，都会导致连接池"虚假消耗"。更深层的问题是，慢查询会长时间占用连接，而连接数用尽后其他正常请求因获取不到连接而超时，最终形成"连接风暴"。 目标拆解与工程约束 连接池参数必须与服务特征匹配：MaxOpenConns、MaxIdleConns、ConnMaxLifetime等参数的设置取决于服务的QPS、单次查询耗时和实例数。过高会导致DB连接资源浪费，过低则导致请求排队超时。需要基于实际压测数据进行调优。 连接泄漏需要自动检测和告警：不能等连接数打满max_connections才发现问题。需要实时监测活跃连接数、空闲连接数和等待获取连接的请求数，在异常趋势出现时及时告警。 慢查询归因需要精确到代码行和调用栈：仅靠DB侧的慢查询日志只能定位SQL，无法定位到Go代码中的调用位置。需要在Go侧实现SQL执行追踪，关联请求ID、goroutine ID和调用栈。 需要在应用层和DB层之间建立熔断机制：当DB连接池连续N次获取连接超时时，应触发熔断降级，快速失败而非无限排队，防止连接风暴破坏整个集群的可用性。 方案设计 核心方案围绕三个组件：连接池监控器、SQL追踪中间件和熔断保护器。 连接池监控器定期采样stats.PoolStats，计算关键指标并上报至Prometheus： type PoolMonitor struct { db *sql.DB interval time.Duration metrics map[string]prometheus.Gauge } func (m *PoolMonitor) Run(ctx context.Context) { ticker := time.NewTicker(m.interval) for { select { case <-ticker.C: stats := m.db.Stats() m.metrics["db_open_connections"].Set(float64(stats.OpenConnections)) m.metrics["db_in_use"].Set(float64(stats.InUse)) m.metrics["db_idle"].Set(float64(stats.Idle)) m.metrics["db_wait_count"].Set(float64(stats.WaitCount)) m.metrics["db_wait_duration"].Set(float64(stats.WaitDuration.Milliseconds())) m.metrics["db_max_open"].Set(float64(stats.MaxOpenConnections)) case <-ctx.Done(): ticker.Stop() return } } } SQL追踪中间件基于database/sql的钩子机制，在每个查询执行前后记录时间、调用栈和请求上下文： type TracedDB struct { *sql.DB slowThreshold time.Duration } func (db *TracedDB) QueryContext(ctx context.Context, query string, args ...any) (*sql.Rows, error) { start := time.Now() caller := captureCaller(2) // 获取调用栈 rows, err := db.DB.QueryContext(ctx, query, args...) elapsed := time.Since(start) if elapsed > db.slowThreshold { traceID := GetTraceID(ctx) log.Warnw("slow query detected", "trace_id", traceID, "query", query, "args", args, "elapsed_ms", elapsed.Milliseconds(), "caller", caller, "rows_affected", getRowsAffected(rows), ) } return rows, err } 熔断保护器基于Google SRE的熔断算法，当连续错误率超过阈值时进入open状态，拒绝所有请求；经过冷却窗口后进入half-open状态，允许少量探测请求通过： ...

背景 这类问题在真实项目里很常见：高并发、复杂依赖、发布频繁、团队协作面广。只有把边界条件提前定义清楚，系统才会在压力下保持稳定。 实践要点 先定义目标：可用性、延迟、成本哪个优先。 把关键路径显式化：超时、重试、降级、回滚。 把策略写进代码和流程，而不是只停留在文档。 代码片段 apiVersion: v1 kind: ConfigMap metadata: name: sample 总结 工程实践最怕“看起来正确”。把策略做成可观测、可验证、可回滚的闭环，才能在生产环境里真正稳定运行。 稳定性不是某个技巧，而是持续的系统化约束。

先识别“慢”的来源 SQL 变慢不一定是缺索引，表膨胀和死元组积累会导致扫描范围扩大、缓存命中下降。 治理流程 建立膨胀指标：表大小、死元组比例、索引膨胀率。 调整 autovacuum 阈值与 cost。 对重度膨胀索引做在线重建。 操作原则 大表维护必须做时间窗规划。 避免维护任务与业务高峰重叠。 维护后验证计划变化而非只看时长。 小结 数据库维护不是“定时跑任务”，而是围绕 workload 变化做持续调参和窗口管理。

背景 这类问题在真实项目里很常见：高并发、复杂依赖、发布频繁、团队协作面广。只有把边界条件提前定义清楚，系统才会在压力下保持稳定。 实践要点 先定义目标：可用性、延迟、成本哪个优先。 把关键路径显式化：超时、重试、降级、回滚。 把策略写进代码和流程，而不是只停留在文档。 代码片段 ctx, cancel := context.WithTimeout(ctx, 200*time.Millisecond) defer cancel() err := client.Call(ctx) if err != nil { return err } 总结 工程实践最怕“看起来正确”。把策略做成可观测、可验证、可回滚的闭环，才能在生产环境里真正稳定运行。 稳定性不是某个技巧，而是持续的系统化约束。

问题画像 线上最危险的不是“改表”，而是“业务和改表耦合发布”：应用已读新字段，但 DDL 还没完成；或者 DDL 成功了，回滚却读不懂新结构。 迁移模型：Expand -> Migrate -> Contract Expand：只做向后兼容变更（加列、加索引、双写入口）。 Migrate：后台回填与数据校验，逐步把读流量切向新字段。 Contract：确认没有旧路径后，再删旧列/旧索引。 Go 侧发布顺序 // 第一步发布：双写 + 旧读优先 func SaveOrder(ctx context.Context, o Order) error { row := model.OrderRow{ ID: o.ID, // old_total 保持兼容 OldTotal: o.Total, // new_total 为新字段 NewTotal: decimalPtr(o.Total), } return repo.Upsert(ctx, row) } // 第二步发布：读新字段，失败回退旧字段 func LoadOrderTotal(r model.OrderRow) decimal.Decimal { if r.NewTotal != nil { return *r.NewTotal } return r.OldTotal } 回填策略 按主键区间分页，避免大事务长时间占锁。 每批记录校验 checksum，把异常写入死信表。 回填作业限速，和在线业务共享数据库 QPS 预算。 观测与止损 指标：回填进度、回填错误率、慢 SQL、锁等待时间。 开关：双写开关、读路径开关、回填暂停开关。 预案：任意阶段都能回到“旧读+旧写”。 常见坑 在 Expand 阶段做非兼容 DDL（例如直接改列类型）。 回填任务不幂等，重跑会污染数据。 只关注“DDL 成功”，忽略“业务一致性成功”。 小结 零停机迁移不是一条 SQL，而是一条发布流水线。把数据库变更当成可灰度、可观测、可回滚的工程流程，风险会从“不可控事故”变成“可管理演进”。

背景 Rust 写后端服务时，数据库访问通常是绕不开的一层。 很多人刚开始用 sqlx 或 tokio-postgres 时，会把关注点放在： 能不能异步查询 类型映射是否方便 宏检查 SQL 是否好用 这些当然重要，但线上跑起来以后，更现实的问题通常是： 连接池应该开多大 请求等连接要等多久 数据库抖动时怎么避免把整个服务拖死 这些问题不处理好，异步只能让你“更高效地把数据库打爆”。 先建立一个基本事实 异步不是无限并发。 你的 Tokio 任务可以很多，但数据库连接永远是稀缺资源。无论是 PostgreSQL、MySQL 还是其他关系型数据库，都不可能让应用无限开连接而没有代价。 所以数据库访问的第一原则不是“尽快发查询”，而是： 连接数可控 排队时间可控 查询超时可控 以 sqlx 为例初始化连接池 use sqlx::postgres::PgPoolOptions; use std::time::Duration; async fn create_pool(database_url: &str) -> Result<sqlx::PgPool, sqlx::Error> { PgPoolOptions::new() .max_connections(32) .min_connections(4) .acquire_timeout(Duration::from_secs(2)) .idle_timeout(Duration::from_secs(300)) .max_lifetime(Duration::from_secs(1800)) .connect(database_url) .await } 这几个参数都很关键： max_connections：连接池上限 min_connections：最小保活连接数 acquire_timeout：拿连接最多等多久 max_lifetime：连接多久轮换一次 尤其是 acquire_timeout，它能防止高峰时请求无止境排队。 连接池大小不是越大越好 很多人看到连接池耗尽，就第一时间把池子调大。 这有时能缓一口气，但经常只是把压力继续往数据库推。 连接池大小应该结合几个因素来定： ...