喜欢把枯燥的技术文档变成"手把手教程"，不讲空话，只讲怎么连、怎么写、怎么优化。
数据库选型花了三个月，POC 测了五家产品，报告写了四十页。选型会上拍板的那一刻，所有人都松了一口气。
然后呢？
然后数据库装上了，用了默认配置，没有监控，没有备份策略，没有开发规范，没有应急预案。三个月后，连接数打满、磁盘快满了没人知道、一次误删表花了两天恢复、慢查询把整个系统拖慢——这个时候才想起来"数据库不是装上就能跑的"。
选型只完成了 30%。剩下 70% 是部署、配置、运维、扩展。这部分做不好，选型时的所有努力都会打折扣。
今天把选型之后的完整落地链路讲清楚。从单机到集群的架构演进、不同负载的参数基线、运维体系搭建、容量规划、团队能力建设。跟着这个流程走一遍，新数据库上线不会慌。
01 部署架构演进：从单机到分布式
数据库的部署架构不是一步到位的，是随着业务增长逐步演进的。
阶段一：单机部署
应用 → 数据库（单机）适用阶段：项目初期，数据量小，并发低。
怎么做：
- 一台服务器，装数据库，配好基础参数
- 本地磁盘存储数据
- 定期手动备份
这个阶段最重要的是把参数配好、备份做好。不要觉得"单机随便跑跑就行"，参数不对，单机的性能也会很差。
阶段二：主备高可用
应用 → 主库（写） ↓ 流复制 备库（只读，故障时提升为主）适用阶段：业务上线运行，不能接受长时间停机。
怎么做：
- 主库处理写入，备库通过流复制同步数据
- 主库故障时，备库提升为主库（自动或手动）
- 备库可以承担部分只读查询，分担主库压力
主备架构的核心是复制延迟控制。同步复制保证数据不丢但影响写入性能，异步复制性能好但有丢数据风险。通常核心业务用同步，非核心用异步。
金仓 KES 的主备部署基于流复制协议，同步和异步模式都支持，配合自动故障切换组件可以实现秒级切换。在一些金融和政务项目里，这是最常用的基础高可用方案。
阶段三：一主多备 + 读写分离
应用 → 主库（写） ↓ 流复制 备库1（只读） 备库2（只读）适用阶段：读压力增大，主库扛不住查询负载。
怎么做：
- 增加备库数量，分散读压力
- 应用层或代理层实现读写分离
- 写入走主库，查询按权重分配到备库
读写分离的关键是复制延迟监控。如果备库延迟过大，读到的是旧数据。需要在应用层处理这个边界情况。
阶段四：集群/分布式
应用 → 代理层 → 数据节点1（分片A） → 数据节点2（分片B） → 数据节点3（分片C）适用阶段：单机数据量或并发量到达极限，需要横向扩展。
怎么做：
- 数据分片，每个节点只存储一部分数据
- 代理层负责路由和结果汇总
- 写入和读取都可以水平扩展
分库分表是最后一步，不是第一步。能垂直扩容的先垂直扩容，能读写分离的先读写分离，扛不住了再分片。
02 初始参数配置：不同负载的基线
数据库装完的默认配置离"生产就绪"差得远。不同负载类型需要不同的参数基线。
OLTP 负载（高并发事务）
核心关注点：写入性能、连接数、事务隔离。
-- 内存配置（以 16GB 服务器为例） shared_buffers = 4GB -- 总内存的 25% effective_cache_size = 12GB -- 总内存的 75% work_mem = 64MB -- 单操作内存，注意总并发数 maintenance_work_mem = 1GB -- 维护操作内存 -- 连接配置 max_connections = 500 -- 按实际需求设，不是越大越好 superuser_reserved_connections = 5 -- WAL/刷盘配置 wal_level = replica synchronous_commit = on -- OLTP 建议 on，保证数据不丢 checkpoint_completion_target = 0.9 wal_buffers = 64MB -- 查询优化器 random_page_cost = 1.1 -- SSD 环境 effective_io_concurrency = 200 -- SSD 环境踩坑提醒：
work_mem不是全局限制，是每个排序/哈希操作的内存上限。如果 max_connections=500，每个连接同时有 2 个大排序，理论最大内存 = 500 × 2 × 64MB = 64GB。所以 work_mem 要结合 max_connections 和实际并发操作数来设。
OLAP 负载（分析查询）
核心关注点：大查询性能、并行计算、批量读取。
-- 内存配置（以 32GB 服务器为例） shared_buffers = 8GB effective_cache_size = 24GB work_mem = 256MB -- OLAP 可以设大一些 maintenance_work_mem = 2GB -- 并行查询 max_parallel_workers_per_gather = 4 max_parallel_workers = 8 max_parallel_maintenance_workers = 4 -- 查询优化器 random_page_cost = 1.1 effective_io_concurrency = 200混合负载
OLTP + OLAP 混合的场景，参数需要折中。更好的做法是：主库跑 OLTP，备库跑 OLAP，通过流复制保持数据同步。
金仓 KES 在这类场景下支持动态内存调整，不需要重启数据库就能修改大部分内存参数。这在做负载切换的时候比较方便——比如白天 OLTP 为主、夜间跑分析报表时动态调大 work_mem 和并行度。
03 运维体系搭建：备份、监控、告警
运维体系不是"出了问题再补"的事，是上线前就该搭好的。
备份策略
三层备份：
| 层级 | 方式 | 频率 | 恢复粒度 | 恢复时间 |
|---|---|---|---|---|
| 全量备份 | pg_basebackup / 物理备份 | 每周一次 | 整个数据库 | 小时级 |
| 增量备份 | WAL 归档 | 持续 | 按时间点 | 小时级 |
| 逻辑备份 | pg_dump / 逻辑导出 | 每天一次 | 单表/单 schema | 分钟级 |
三层备份缺一不可。全量备份兜底，增量备份支持时间点恢复，逻辑备份用于单表误删的快速恢复。
监控体系
核心监控指标：
| 维度 | 指标 | 告警阈值 |
|---|---|---|
| 可用性 | 数据库进程状态 | 进程异常立即告警 |
| 连接 | 当前连接数 / 最大连接数 | > 70% 告警 |
| 磁盘 | 数据目录使用率 | > 80% 预警，> 90% 紧急 |
| 复制 | 主备延迟（秒） | > 10 秒告警 |
| 性能 | 慢查询数量 | 每分钟 > 10 条告警 |
| 资源 | CPU、内存、I/O 利用率 | CPU 持续 > 80% 告警 |
告警通道
- 紧急告警（数据库不可用、磁盘满）：短信 + 电话
- 重要告警（连接数超限、复制延迟大）：钉钉/企微
- 预警（磁盘 80%、慢查询增多）：邮件 + 工单
告警不能只报"磁盘 85% 了"，要报"磁盘 85%，按当前增长率 15 天后满，建议本周内扩容"。带预测的告警才有行动价值。
金仓 KES 配合 KEMCC 统一管控平台，可以把监控、告警、巡检集中到一个界面管理。对于有多套数据库实例的场景，集中管控比逐台登录查状态效率高很多。日常巡检可以自动化出报告，不用人工逐台检查。
04 容量规划：按增长率预测，提前扩容
容量规划的核心不是"查磁盘用了多少"，是"预测还能撑多久"。
记录趋势
每天固定时间记录以下数据，连续 30 天：
- 数据库大小
- 当前连接数 / 历史最大连接数
- 缓存命中率
- CPU 利用率（日均、峰值）
算增长率
日均增长量 = (当前大小 - 30 天前大小) / 30 剩余天数 = (磁盘总容量 × 80% - 当前已用) / 日均增长量注意用 80% 算，不是 100%。到了 80% 就该告警了，不能等到 100%。
提前规划
| 剩余天数 | 行动 |
|---|---|
| < 30 天 | 紧急扩容 |
| 30-60 天 | 启动扩容流程 |
| 60-90 天 | 评估扩容方案 |
| > 90 天 | 持续关注 |
容量瓶颈也不只是磁盘。连接数打满、内存不够、CPU 持续高位——这些都需要持续监控和趋势分析。
05 团队能力建设：人比工具重要
数据库出问题，最后是人来解决。团队能力跟不上，再好的工具和架构都没用。
开发规范
给开发团队定几条硬规矩：
- SQL 上线前必须过执行计划。不加索引的 SQL 不能上线。
- 禁止在生产库做 DDL。改表结构走变更流程，先在测试库验证。
- 禁止全表扫描查询。WHERE 条件必须有索引。
- 禁止 N+1 查询。一次能查完的不要循环查。
- 连接用完必须释放。连接泄漏是最隐蔽的性能杀手。
DBA 手册
至少要有以下内容：
- 日常巡检清单（每天/每周/每月做什么）
- 备份恢复流程（怎么恢复单表、怎么恢复整个库）
- 故障排查流程（慢查询怎么定位、连接打满怎么处理、锁冲突怎么解）
- 应急预案（主库故障怎么切换、磁盘满怎么处理）
应急预案
每个场景都要有书面预案，不能只存在某个人脑子里：
| 场景 | 预案要点 |
|---|---|
| 主库宕机 | 备库提升步骤、连接切换方式、回退条件 |
| 磁盘满 | 紧急清理路径、临时扩容方式、根因排查流程 |
| 连接打满 | 定位异常连接、kill 策略、连接池调整 |
| 误删数据 | 时间点恢复步骤、逻辑备份恢复流程 |
| 复制中断 | 断点定位、重建复制流程 |
对比：不同阶段的数据库能力需求
| 阶段 | 架构 | 运维重点 | 团队要求 | 工具需求 |
|---|---|---|---|---|
| 初期（单机） | 单机部署 | 参数配置、备份 | 1 人兼管 | 基础监控 |
| 成长期（主备） | 主备高可用 | 复制监控、切换演练 | 1-2 人专职 | 监控告警 + 备份自动化 |
| 扩展期（读写分离） | 一主多备 | 负载分配、延迟控制 | 2-3 人专职 | 读写分离代理 + 性能分析 |
| 成熟期（集群） | 分布式集群 | 分片管理、容量规划 | 专职 DBA 团队 | 统一管控平台 + 自动化运维 |
决策框架：按团队规模和业务阶段选择投入重点
| 团队规模 | 业务阶段 | 投入重点 | 可以暂时不做的事 |
|---|---|---|---|
| 1 人兼管 | 项目上线初期 | 参数配置 + 备份 + 基础监控 | 自动化运维、统一管控平台 |
| 1-2 人 | 业务稳定运行 | 主备高可用 + 监控告警 + 开发规范 | 分布式集群、精细化容量规划 |
| 2-3 人 | 业务快速增长 | 读写分离 + 容量规划 + 应急预案 | 分库分表 |
| 专职 DBA 团队 | 核心业务 | 集群部署 + 全链路监控 + 性能基线 + 自动化 | — |
核心原则：投入匹配阶段。不要在单机阶段搞分库分表，也不要在集群阶段还靠人工巡检。
深度分析：为什么选型之后总是"用不好"
很多团队数据库用不好的根本原因是：选型和落地是两拨人。
选型的人做完 POC、出了报告、开了评审会，项目移交运维团队。运维团队拿到的是一个"可以跑"的数据库，但不是"生产就绪"的数据库——参数是默认的、没有监控、没有备份策略、没有开发规范。
这种"断档"导致选型的成果无法落地。选型时的要求（性能指标、高可用能力、兼容性承诺）在落地阶段被稀释了。
解决这个问题的方法只有一个：选型和落地是同一个团队负责到底。选型的人要参与部署、参与参数调优、参与监控搭建。只有把选型报告里的承诺变成生产环境的实际配置，选型才算真正完成。
总结
数据库选型之后的落地链路：部署架构从单机逐步演进到集群，参数按负载类型配基线，运维体系上线前就搭好，容量规划看趋势不看单点，团队能力是最终保障。
选型只完成 30%，剩下 70% 在落地。部署、配置、运维、扩容、团队——每一个环节都是"用到位"的一部分。
选型的时候看的是"能不能"，落地的时候看的是"好不好"。能把"能不能"变成"好不好"的团队，数据库这块才算真正过关。
后续我会继续分享数据库运维实战、性能调优这些话题，跟着我一篇篇学，数据库这块就没问题了。
有问题评论区见。
喜欢把枯燥的技术文档变成"手把手教程"。关注我，数据库这块我们一起搞定。