数据库运维需分四层能力：基础认知（理解存储、查询、事务机制）、日常运维（监控、备份、变更、慢查治理）、进阶能力（分库分表、高可用、性能定位、成本优化）、专家视角（SQL规范、容量规划、故障复盘、研发协同）。
一、基础认知：理解数据库运行的核心逻辑
数据库不是黑盒，运维首先要懂它怎么工作。SQL数据库本质是持久化存储+查询引擎+事务管理的组合体。你需要清楚数据如何落盘（页、区、日志文件）、查询如何解析执行（解析器→优化器→执行器）、事务如何保证ACID（WAL机制、锁与MVCC）。不深究源码，但得知道慢查为什么慢（是全表扫描？锁等待？还是内存不足？），主从延迟为什么发生（网络抖动、大事务、从库IO瓶颈），这些判断都源于对底层逻辑的理解。
二、日常运维：稳住系统不掉线的关键动作
日常不是“等告警再处理”，而是建立主动防御习惯：
- 监控必须覆盖三层：实例层（连接数、QPS、TPS、缓冲池命中率）、OS层（CPU/内存/磁盘IO/网络）、存储层（binlog/redo log增长速率、磁盘剩余空间）；
- 备份要可验证、可恢复：不只是mysqldump或xtrabackup跑完就完事，每周至少一次还原演练，检查point-in-time恢复是否精准；
- 变更务必走流程：DDL操作（尤其加索引、改字段）在大表上极易阻塞业务，优先用pt-online-schema-change或MySQL 8.0+的INSTANT/ALGORITHM=INPLACE；
- 慢查治理常态化：每天看slow log前20条，结合explain分析执行计划，重点盯type=ALL、rows远大于实际结果集、Using filesort/Using temporary的SQL。
三、进阶能力：从救火员到架构协作者
当系统规模上来，单实例扛不住，运维就要参与选型与协同设计：
- 分库分表不是首选项：先压测、调优、读写分离、缓存穿透防护；真要拆，明确分片键选择逻辑（避免跨分片JOIN和排序），评估中间件（ShardingSphere vs MyCat）的运维复杂度；
- 高可用方案要匹配业务容忍度：金融类用MGR多主+仲裁节点，电商类常用基于GTID的异步复制+Orchestrator自动故障转移；别只看切换时间，更要关注脑裂防护与数据一致性兜底；
- 性能瓶颈定位需串联分析：看到CPU高，不能只杀进程——结合perf top、pt-pmp看热点函数，再关联SQL执行计划与锁状态（sys.innodb_lock_waits）；
- 成本意识要前置：归档冷数据（partition pruning + event调度）、压缩行格式（ROW_FORMAT=COMPRESSED）、合理设置innodb_buffer_pool_size（通常设为物理内存60%~75%，非固定80%）。
四、专家视角：构建可持续的数据库治理体系
专家级运维不再聚焦单点问题，而是推动机制落地：
- 制定SQL准入规范：禁止SELECT *、要求WHERE必带索引字段、限制JOIN表数≤3、INSERT/UPDATE必须指定字段列表，通过SQL审核平台（如Yearning、Archery）卡点；
- 建立容量基线模型：按业务增长率预估6个月后的QPS、存储、连接数，反推硬件配置与扩容窗口，避免临时加机器；
- 沉淀故障复盘文档：每次P1/P2故障后输出RCA（Root Cause Analysis），归类为配置类、SQL类、架构类、人为类，并更新checklist与应急预案；
- 推动DBA与研发共建：组织索引设计评审会、提供EXPLAIN解读培训、共建慢SQL排行榜，让优化意识下沉到开发侧。
