数据库运维实践：从选型到高可用的落地路径
数据库是业务系统里最不能“重启试试”的一层。本页从极客运维的日常视角出发，围绕选型评估、备份恢复、高可用架构、慢查询治理与容量规划几个层面，整理一套可复用的数据库运维方法，帮助你把“能跑”变成“跑得稳、查得快、挂得起”。
选型与部署：先想清楚再动手
MySQL 适合事务型业务，PostgreSQL 在复杂查询与扩展类型上更从容，Redis 承担缓存与热点计数，MongoDB 适合文档结构多变场景。选型不是比谁更新，而是看读写比例、一致性要求和团队熟悉度。
- 明确业务读写模型与峰值 QPS
- 评估备份窗口与恢复 RTO/RPO
- 部署前完成参数基线模板
- 预留监控与慢日志采集通道
部署阶段把配置文件、初始化脚本和参数基线纳入版本管理，后续扩容与故障恢复才有据可依。
备份与恢复：没有验证过的备份等于没有备份
全量备份 + binlog 增量是 MySQL 的常规组合，PostgreSQL 可用 pg_basebackup 配合 WAL 归档。关键不是备份命令写得多漂亮，而是定期做恢复演练，把恢复时间量化成可跟踪的指标。
每日
全量备份 + 校验
每周
恢复演练 + 记录
每月
容量与保留策略复盘
高可用与故障切换
主从复制是基础，但真正的可用性来自切换演练。MHA、Orchestrator 或云托管方案各有取舍，核心是明确切换判定条件、脑裂防护和回切流程。
- 复制延迟纳入告警阈值
- 切换脚本必须可重复执行
- 应用侧连接串支持快速切换
高可用拓扑图建议和监控看板放在一起，值班时能一眼看到主从角色与延迟状态。
慢查询治理与容量规划
慢查询日志要开，但更重要的是定期聚合分析。把执行次数多、平均耗时高的 SQL 挑出来，结合执行计划判断是缺索引、索引失效还是查询写法问题。容量规划则要结合磁盘增长曲线和业务增长预期，提前做分库分表或归档评估。
| 治理项 | 常见问题 | 处理方向 |
|---|---|---|
| 慢查询 | 全表扫描、索引未命中 | 补索引、改写 SQL |
| 连接数 | 连接池配置不合理 | 调优池大小与超时 |
| 磁盘容量 | 日志与数据增长过快 | 归档、分区、扩容 |
常见问题 FAQ
Q：主从延迟突然升高怎么办？
先看大事务与批量写入，再检查从库 IO 与 SQL 线程状态，必要时临时降低写入并发并观察复制位点。
Q：备份文件多大算合理？
没有绝对标准，关键是备份耗时与恢复耗时在可接受窗口内，并且保留策略与存储成本匹配。
Q：什么时候该考虑分库分表？
单表数据量增长导致索引维护成本明显上升、DDL 窗口难以安排时，再结合业务查询模式评估拆分方案。