背景 这类问题在真实项目里很常见：高并发、复杂依赖、发布频繁、团队协作面广。只有把边界条件提前定义清楚，系统才会在压力下保持稳定。 实践要点 先定义目标：可用性、延迟、成本哪个优先。 把关键路径显式化：超时、重试、降级、回滚。 把策略写进代码和流程，而不是只停留在文档。 代码片段 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，它能防止高峰时请求无止境排队。 连接池大小不是越大越好 很多人看到连接池耗尽，就第一时间把池子调大。 这有时能缓一口气，但经常只是把压力继续往数据库推。 连接池大小应该结合几个因素来定： ...