咱们直接聊数据库运维。这活儿看着不起眼，但真出了岔子，老板能急得跳脚——系统宕机、数据丢失、响应卡成PPT，哪一样都不是小事。所以，手里没几道硬核试题撑腰，心里总不踏实。今天我就整理几道数据库运维的必备试题，每道都附上详细解析，不是那种百度一搜就有的水货，而是实实在能帮你避坑的干货。咱们边看边琢磨，就当跟同行聊天。
第一道题：线上业务突然变慢，CPU飙到90%以上，你第一件事该干啥？别急着重启，也别慌着查慢查询。正确答案是：先看连接数。很多运维兄弟一上来就抓慢SQL，但往往最坑的是连接池爆了。比如MySQL默认的maxconnections是151，如果业务量突增，连接数一超，服务器直接拒绝新请求，CPU全耗在排队上。解析：连接数飙高时，优先用看看有没有“sleep”状态堆积。那些长时间空闲的连接，要么是应用层没释放，要么是连接池配置太小。这时候跑个命令，清理掉僵尸连接，CPU能瞬间降下来。记着，别让数据库替应用背锅，运维要会“掐源头”。
第二道题：主从复制延迟了5分钟，怎么快速定位？有人二话不说就重启从库，结果数据全乱套。正确的打开方式：先查里的，但别迷信这个值。它只代表从库执行binlog的滞后时间，如果网络抖动或大事务卡住，这个值可能虚高。解析：更靠谱的方法是看和是不是一致。不一致说明中继日志没追上。再查和，这两个错误代码直接告诉你哪里卡壳。比如1062错误是主键冲突，那就得去主库检查自增ID设置；如果是1032错误，说明从库找不到更新行，可能是主从数据不一致。别急着修，先搞清楚是IO线程慢还是SQL线程慢——IO慢就调网络或磁盘，SQL慢就看看大事务或索引优化。
第三道题：数据误删了整张表，你手里只有全量备份，但备份是6小时前的，怎么恢复？标准答案：别直接恢复全量，那会丢6小时的数据。正确做法是：先恢复全量到一台临时库，再用binlog把6小时内的操作重放回去。解析：具体步骤是，先把备份文件（比如mysqldump或xtrabackup）恢复到另一台服务器，记录下备份时刻的binlog位置。然后从主库的binlog里，提取从备份时刻到误删操作之前的日志，用工具过滤出来，再应用到临时库。注意：如果误删操作本身是，你得在binlog里把这条语句删掉，否则恢复完又被删一次。更要命的是，如果binlog没开启或者被清理了，那就真只能认栽。所以，运维的底线是：不管多忙，binlog必须开，保留期至少设7天。
第四道题：数据库缓存命中率只有20%，怎么调？有人直接改大缓存容量，结果内存溢出，系统更卡。正确答案：先分析缓存失效的原因。解析：缓存命中率低，常见原因有两个：一是查询模式不匹配，比如大量用导致缓存碎片多；二是缓存空间太小，但盲目扩容前，先看和，如果读请求频繁，但实际缓存里数据少，那可能是索引没设计好。比如一张表有100万行，但查询只频繁用某几个字段，那必须建复合索引，否则每次查都全表扫描，缓存根本存不下。另外，检查，如果很高，说明表缓存不够，调大参数，但别超过内存的10%。
第五道题：数据库服务器磁盘满了，但业务还在跑，怎么应急？有人直接删日志文件，结果系统不知道日志被删，依然继续写，导致进程挂掉。正确做法：先查大文件，再用软链接或压缩应对。解析：用找最大的表或日志。如果是binlog占空间，别直接删，用语句清理指定时间前的日志。如果是错误日志或慢查询日志太大，可以压缩后改名，再新建一个空文件。更骚的操作是：把日志目录挂载到更大的磁盘分区上，或者用找到已删除但还在被占用的文件，用腾空间。但记住，这只是治标。治本要看数据归档策略——比如冷数据定期迁移到对象存储，或者开启表分区，把历史分区直接DROP掉。
第六道题：从库突然报错“Slave has more relay logs than master”，怎么处理？有人直接重置从库，结果主从数据差得离谱。正确答案是：先分析中继日志损坏原因，再决定修复策略。解析：这个错误通常是因为从库重启或网络中断后，中继日志的binlog位置和主库对不上。第一步，用看和，如果差距很大，说明有未执行的中继日志。第二步，如果错误是，表示binlog文件损坏，那就得去主库用检查对应文件，看是不是有乱码。修复时，别直接，那会丢掉所有中继日志。正确姿势是：先，然后到某个安全的binlog位置，再手动重放剩下的。实在不行，才考虑用重新拉取，但必须确保主库的binlog文件还在。
第七道题：数据库突然只读，怎么排查？有人直接改，结果写操作导致数据不一致。正确答案是：先查磁盘空间和事务状态。解析：MySQL自动进入只读状态，多半是磁盘满了或InnoDB事务回滚卡住了。用看磁盘，如果超过90%，先清理大文件，比如临时表或binlog。如果磁盘正常，查里的，看有没有事务阻塞。比如有一个长事务在跑，导致所有写操作等待，那可以掉这个事务，或者等它自动回滚。注意：如果是因为主从切换导致只读，那就得配合应用层改连接配置。千万别硬改，否则数据写一半，整个集群一致性崩了。
第八道题：晚上要上线大版本升级，怎么做到零宕机？有人直接停服升级，第二天被老板骂到自闭。正确答案：用灰度切换和读写分离。解析：第一步，搭建一套新版本的环境，用binlog同步持续拉取老库的数据。第二步，在业务低峰期，把应用层的读流量切10%到新库，监控慢查询和错误日志。如果跑了一小时没问题，再逐步切写流量。这里的关键是：切写流量时，必须用数据库代理层（比如ProxySQL或HAProxy）来处理，不能直接改应用连接字符串。第三步，等新库完全接管后，老库保留24小时作为回滚点。如果升级过程中发现性能问题，比如新版本优化器改了执行计划导致某些查询变慢，那就得回滚。记住，零宕机的核心不是技术多牛，而是预案做得够细——包括回滚脚本、监控指标、值班人员电话，缺一不可。
总结一下，数据库运维这行，光会敲命令不行，得懂业务逻辑和数据流。这些试题看着是技术题，实际考的是你遇到问题时，能不能快速分清“现象”和“本质”。比如CPU飙升，本质可能是连接泄漏；主从延迟，本质可能是大事务或网络抖动。别总想着用重启解决一切，那只会掩盖问题。平时多练练这些场景，把解析里的细节吃透，下次真出事了，你就能像老司机一样，稳稳地踩刹车、打方向盘。毕竟，数据库稳了，大家才能安心下班。
