数据库运维这事儿，听起来挺技术，其实说白了就是管好数据，别让它丢了、慢了、出岔子。很多公司觉得找个 DBA（数据库管理员）只要装个软件、写几条 SQL，等真出了问题才发现，运维这活儿远不止表面那点事。我接触过不少刚入行的运维新人，他们一开始总以为每天就是盯着监控面板，看 CPU、内存、磁盘利用率，谁出告警就加台服务器，结果干了几个月，发现系统还是动不动就崩，老板一问三不知。这背后的问题，其实就在于大家把数据库运维想得太简单了。
先说最基础也最容易被忽视的——备份与恢复。很多人觉得备份就是跑个脚本，每天备份一次，万事大吉。可真出过事儿的人都知道，备份没验证，等于白做。我有个朋友在某家互联网公司做运维，一次凌晨磁盘故障，数据库直接挂掉，他赶紧拿备份恢复，结果发现备份文件早在三天前就坏了，原因很简单——服务器定时备份，但没人检查备份文件是否完整。只能从异地容灾系统恢复，损失了整整一天的数据，老板差点把他开了。这事儿告诉我们，备份不只是跑脚本，得定期做恢复演练，模拟真实场景，比如误删表、主库崩溃，看看能否在 10 分钟内把数据救回来。还要考虑备份策略的多样性：全量、增量、日志备份，各有用途。比如凌晨跑全量备份，白天每隔一小时跑增量备份，日志备份实时传输到异地，这样最多只会丢几分钟的数据。很多公司为了省钱，只保留一周的备份，等碰上勒索病毒，数据被加密，才发现一周前的备份也不够用，因为病毒早就潜伏在系统里了。所以备份的保留周期也得根据业务需求定，至少 30 天起步，关键数据甚至要保留一年。
再说说性能调优，这活儿比备份还磨人。数据库慢，用户骂，老板催，运维就得背锅。可问题的根源往往不在数据库本身，而在应用层——程序员写的 SQL 太烂。我见过一个电商平台，双十一大促那天，用户下单页面直接卡死，运维查了半天，发现是订单表里某条 SQL 没加索引，导致全表扫描，一秒内扫描了上千万行数据。程序员当时为了赶工期，随手写了个 ，这种子查询在数据量小的时候还能接受，等用户量上千万，性能直接崩。运维这时候就得跟开发掰扯：你们写 SQL 能不能有点常识？但光掰扯没用，得主动介入。比如打开慢查询日志，定期分析，找出执行时间超过 1 秒的 SQL，然后给开发发邮件，附上优化建议：加索引、改写语句、分表分库。还要做压力测试，模拟用户量翻倍时系统的表现。有的运维会搞自动化工具，每天跑一次 SQL 审核，把性能差的 SQL 直接拦截，不让它们上线。这活儿干久了，你会发现性能调优不光是技术活，更是沟通活——让开发理解，数据库不是万能容器，SQL 写不好，换再贵的服务器也白搭。
安全性这块，我见过太多血泪教训。很多公司把数据库直接暴露在公网上，端口对全网开放，连防火墙都不设，结果被黑客扫描到，直接拖库。前阵子某家教育平台数据泄露，几百万用户的姓名、电话、身份证号全被挂在暗网上卖，事后调查发现，数据库管理员竟然用默认密码 “admin123”。运维的职责里，安全绝对排第一位。密码要定期更换，而且要复杂，大小写字母加数字加符号，至少 16 位。权限要最小化，开发人员只能读，不能写，更不能删表。敏感字段要加密，比如身份证号、银行卡号，存储时用 AES 加密，读取时再解密，即使数据库被拖走，黑客也看不懂。还要做审计日志，记录谁在什么时候登录了数据库，执行了什么操作。我认识一个运维老手，他会在数据库前加一层代理，所有 SQL 必须经过代理，代理负责鉴权、脱敏、限流，这样即使运维自己的密码泄露，黑客也拿不到核心数据。安全这事儿平时看着麻烦，真出事时，后悔都来不及。
监控告警是运维的眼睛，但很多人把这活儿干成了摆设。装个监控软件，设一堆阈值，比如 CPU 超过 80% 就告警，磁盘空间低于 10% 就告警，结果每天收到几百条告警，运维麻木了，看都不看。真出问题时，告警反而淹没在噪音里。我见过最离谱的案例：某公司数据库磁盘空间只剩 1% 了，监控连续发了三天告警，运维觉得是日常告警没在意，结果第四天数据库写不进去数据，业务瘫痪了半天。监控不能只设通用阈值，得根据业务特点定制。比如电商平台，大促期间 CPU 长期在 90% 以上，这不算异常，但凌晨 3 点 CPU 突然飙到 90% ，那肯定是有人在跑慢查询。还要监控慢查询趋势、锁等待时间、连接数变化、复制延迟等专业指标。比如主从复制延迟超过 10 秒，就必须立刻排查，否则从库数据滞后，用户查询到的都是过期信息。告警要分级：P0 级别是数据库完全不可用，必须在 5 分钟内响应，直接打电话；P1 级别是慢查询导致性能下降，可发邮件，30 分钟内处理；P2 级别是磁盘空间不足，自动扩容或通知运维手动清理。这样运维才能把精力花在刀刃上，而不是被琐事淹没。
版本升级和迁移看似简单，实际坑特别多。很多运维图省事，直接在生产库上执行升级，结果新版本和旧系统不兼容，存储过程报错、触发器失效，业务直接挂掉。我有个前同事，给客户的 Oracle 数据库从 11g 升到 12c，没做充分的兼容性测试，升级后发现一个关键存储过程调用报错，因为新版本改了语法，客户投诉了一整天。正确的做法是先在测试环境跑一遍，模拟线上流量，跑个一两天，看看有没有异常。迁移也是如此，数据量大时直接复制容易丢数据或超时。我见过一种方案：用 DataGuard 做物理复制，先全量同步，再增量同步，等延迟降到 0 再切换主库，整个过程业务几乎无感知。还要准备回滚计划，万一切换后出问题，能立刻切回老库。很多运维以为迁移完就完事了，结果忘了清理老库的临时文件，导致磁盘空间爆满。每个步骤都要写文档，操作前确认，操作后验证，做到万无一失。
自动化运维是当前趋势，但很多人理解偏了，以为自动就是写几个脚本。真正成熟的自动化是从部署、备份、监控、扩容到故障恢复的全链路自动化。比如用 Ansible 批量部署数据库，几十台机器几分钟搞定，每台配置都一样，不会出现人为失误。备份自动化：每天凌晨自动跑全量备份，备份完成后自动传到异地，再自动验证备份文件是否完整。扩容自动化：监控到磁盘空间低于 20% 时，自动触发扩容脚本，给数据盘加 100G，然后自动通知运维。故障恢复自动化：监测到主库宕机，自动把从库切换成主库，整个过程不超过 30 秒。我有个朋友在游戏公司，数据库经常被玩家刷爆，后来搞了个自动化限流工具，当连接数超过阈值，自动拒绝非核心业务的查询，保证核心玩家能正常登录。这看似简单，背后要写几百行代码，还得反复测试，确保不会误杀正常请求。自动化不是为了省事，而是让运维从重复劳动中解放出来，去解决更复杂的问题。
聊聊文档和知识沉淀。很多运维干了好几年，经验全靠脑子记，等离职了，接手的人一脸懵。数据库的架构图、备份策略、权限分配、故障处理流程，都得写清楚。我见过一个运维，每次解决问题后，顺手在 Wiki 上记一笔：今天遇到什么故障，怎么排查的，用了什么命令，怎么解决的。几个月下来，Wiki 里积累了上百篇案例，新人遇到类似问题直接搜索，几分钟就搞定，不用再抓瞎。文档不只是给后人看，也是给自己看的。数据库环境总在变，半年前你设的某个参数，半年后可能忘了为什么这么设，文档一翻就明白。而且文档要定期更新，每次变更后立马同步，别等到年底统一整理，那时候早忘光了。知识分享也很重要，团队每周开个半小时的复盘会，把最近遇到的故障和解决方案摆出来，大家一起讨论，避免其他人踩同样的坑。这事儿干久了，整个团队的水平都会提升，遇到问题不再慌，而是有条不紊地按流程处理。
