数据库运维考试这道坎，每个DBA都得迈过去。不管是刚入行的新人，还是干了三五年的老手，碰上那些高频考题，有时候真能让你当场卡壳。我见过不少搞运维的朋友，平时调参数、查慢查询、搭主从复制，手速快得飞起，可一到考试环节，反而栽在一些基础题上。原因很简单——实战靠肌肉记忆，考试考的是原理和细节。今天这10道高频题，我挑的都是面试和认证考试里反复出现的实战型题目，不跟你扯虚的，每一道都对应真实场景。你试试看，能答对几道？别急着翻答案，先自己在脑子里过一遍。
第一题：慢查询优化，你第一步该做什么？很多人上来就加索引，或者调参数，这是大忌。正确的做法是先定位——用或者抓出具体的慢SQL，然后用分析执行计划。我见过最典型的案例：一个电商系统的订单查询，每次响应要8秒，运维大哥二话不说把翻了三倍，结果只降到5秒。后来一查，发现是条件里用了函数包裹索引字段，导致索引失效。优化SQL本身，比调参数管用得多。这道题考的就是你是否有“先诊断后治疗”的思维，而不是拍脑袋动手。
第二题：主从复制延迟的根因排查，你会从哪几个维度入手？别只盯着那个值，它有坑——当主库大事务执行时，从库的延迟值会先跳高再归零，容易误判。真正的排查路径是：一看里的，如果中继日志积压，说明从库IO线程卡了；二看从库的，有没有长时间运行的查询；三看磁盘IO的和，复制线程写数据时如果磁盘扛不住，延迟必然涨。我处理过一个案例，从库延迟稳定在30秒，排查一圈发现是设成了1，每次提交都刷盘，把性能拖死了。这道题考的是你对复制机制的底层理解，不是背参数。
第三题：数据库连接数被打满，该怎么快速应急？别上来就重启服务，那是下下策。第一件事是检查当前值和实际使用量，用对比。如果确实满了，可以临时调大，但治标不治本。更关键的是找出谁在占连接——用看每个连接的和，很多是应用层没做连接池，或者有慢查询卡住了。我见过一个奇葩案例：某个业务线写了个死循环，每毫秒新建一个连接又不关闭，几分钟就打满。这时候得协调业务方杀进程，而不是傻等。这道题考的是应急思维——先止损，再排查，别慌。
第四题：备份恢复，你的策略能扛住“删库跑路”吗？很多人说“我每天全量备份”，但真要恢复时发现要先把全量备份导入，再追增量的binlog，如果binlog没按时间切分，恢复时间能拖到天荒地老。正确的做法是：全量备份加定期binlog归档，并且binlog按切割，保留至少72小时。另外，恢复前一定要测试——我认识一个运维，备份文件有7TB，恢复时才发现压缩包损坏，直接凉了。这道题考的是你对备份粒度和恢复时间的理解，不是备份了就行，要能真正恢复。
第五题：事务隔离级别，你能讲清楚MVCC和锁的关系吗？面试官最爱问这个。和的区别，很多人背得溜，但一细问就露馅。比如：在下，为什么一个事务里两次结果一致？因为MySQL用和实现了快照读，读的是事务开始时的版本。而每次都生成新快照，所以能看到其他事务已提交的更改。实战里，高并发场景下如果用，间隙锁容易引发死锁，这时候该考虑降级到。这道题考的是你能不能把理论用到实际调优里。
第六题：索引失效的常见场景，你能列出至少5种吗？这不是死记硬背，而是实战踩坑经验。我总结最常见的：1. 条件里对索引列用了函数，比如；2. 隐式类型转换，比如字段是字符串，传了数字；3. 左模糊查询，比如；4. 联合索引没遵循最左前缀原则，跳过了第一列；5. 优化器认为全表扫描比用索引更快，比如表数据量太小或者返回行数占比过高。每个场景背后都有真实案例。比如有个报表系统，查询突然变慢，查了半天发现是条件里字段从改成了，但代码没更新传参类型。这道题考的是你排查SQL性能问题的敏锐度。
第七题：数据误删后，如何找回？这题考的是你的应急处理流程。第一步：立刻设置？错，那是找死。正确做法是：先，然后从最近的binlog里找到误删操作前的点，用工具解析出来，出相关SQL，反向生成或语句。如果开启了，binlog一般不会丢。但有个前提——你之前要配了，因为格式下没法精确还原。我处理过一个案例，同事不小心了全表，幸好binlog开着，我在日志里找到前的行数据，一条条插回去。这道题考的是你对binlog机制的熟悉程度，以及临场不乱的执行力。
第八题：数据库高可用方案，你选MHA、Orchestrator还是MGR？别只背特性，要结合业务场景。比如公司业务对数据一致性要求极高，那MGR的强同步模式可能更合适，但它的性能损耗大，网络抖动时容易踢节点。如果业务能容忍秒级延迟，MHA是成熟方案，但要注意它的故障切换依赖和位置，配置错了切换时会翻车。我见过一个团队用Orchestrator，结果因为拓扑发现逻辑有问题，把主库误判为从库，直接切走导致写丢失。这道题考的是你对不同方案优缺点的权衡，而不是选一个“最好”的。
第九题：内存和磁盘参数调优，你如何判断瓶颈在哪儿？很多人一上来就调，但那是拍脑袋。正确的思路是用看，如果命中率低于99%，说明缓冲池不够大。再看磁盘IO——用看和，如果超过20毫秒，说明磁盘有压力。有个经典误区：有人把调到2GB，结果宕机后恢复时间长达半小时，因为重做日志太大。调优要从小步快跑开始，每次改一个参数，观察效果，别一锅端。这道题考的是你用数据说话的能力，不是凭感觉。
第十题：面对一个从未见过的数据库故障，你的排查思路是什么？这是压轴题，考的是综合素养。我的套路是：先看监控——CPU、内存、磁盘IO、网络延迟，哪个异常？再看日志——、、系统日志，有没有报错？然后试重现——能不能复现故障？如果复现了，用或抓调用栈。缩小范围——是单表问题还是全局问题？是查询问题还是写入问题？我经历过一个玄学故障：数据库每隔两小时卡死一次，排查了三天，发现是系统定时任务触发了全量备份，备份时锁住了所有写操作。这道题考的不是知识储备，而是方法论——你能否像侦探一样，用逻辑链把问题定位出来。
这10道题，每一道都是我这些年踩坑、复盘、总结出来的。你不用全答对，但每道题背后的思维方式，比答案本身重要100倍。数据库运维不是背参数手册，而是面对真实场景时，能快速判断、果断动手、事后复盘。下次碰到考试或者面试，别慌，把这些问题当朋友聊天的引子，思路通了，答案自然就来了。你答对了几道？心里有数就好。
