我跟你说，数据库运维这行当，面试题看着高大上，聊开了其实也就几类。很多人一进面试间就紧张，觉得必须把那些晦涩的算法和原理背得滚瓜烂熟才行。但你真去面过几回就会发现，面试官问的往往不是让你死记硬背，而是看你有没有遇到过真实场景。比如最常见的，问你“数据库突然变慢了，你第一步做什么”。别急着甩出一堆索引优化、缓存策略，先问问自己，有没有真实排查过问题。我见过不少新人，张口就是“看慢查询日志”，但实际工作中，第一步往往是“看监控面板”，看看 CPU、内存、IO 是否爆了。这就是实战和书本的差距。
再比如，很多人面试时被问到“主从复制延迟怎么办”。网上答案一堆，说什么调整同步模式、优化网络带宽，听着都对，但面试官更想听的是你有没有真正解决过这类问题。我认识一个运维老哥，他在公司遇到一次复制延迟导致业务数据不一致，他没急着调参数，而是先查了从库的硬件负载，发现是磁盘 IO 跑满了，因为有人在从库上跑了一个大查询。解决完这个，延迟自动降下来了。这才是真正的答案：不是背概念，而是讲清楚你遇到过什么、怎么排查、怎么解决。面试官听你讲完，会觉得你靠谱，而不是书呆子。
还有一类高频题，就是“数据库备份策略怎么设计”。很多人直接说“全量加增量”，但面试官会追问“增量怎么做的，binlog 怎么管理的，恢复时间能控制在多少”。光说理论没用，必须讲出具体细节。比如你之前在公司，业务要求恢复时间不超过 1 小时，你发现全量备份要 4 小时，那你怎么优化？是用了并行备份，还是选了更快的存储，或者把备份周期缩短？这些才是面试官想听的。我见过一个候选人，他说团队把备份脚本写成了自动化，还加了报警，备份失败时短信直接打到值班手机。这种回答，一听就是干过活的。
当然，面试里也少不了听起来高大上的问题，比如“你在高并发场景下怎么优化数据库”。这时候不要慌，别上来就说分库分表、读写分离，先问清楚业务场景。是写多读少，还是读多写少。如果是读多写少，加缓存就能解决；如果是写多读少，那才需要考虑分库。我认识一个朋友，他面试时被问到这个问题，没急着给方案，而是反问面试官“你们现在的业务峰值是多少，是金融交易类还是内容类”。面试官当场笑了，说你这问题问得很到位。因为真正懂行的人不会凭空给方案，而是先理解业务痛点。这才是数据库运维的核心：技术是死的，业务才是活的。
另外，很多人害怕被问到“数据库事务隔离级别”这类基础题，觉得太简单说出来显得没水平。但别小看它，面试官有时就是拿它测你的基本功。比如问你“RR 级别下，怎么避免幻读”，如果你只会背“用间隙锁”，就露怯了。你需要讲清楚间隙锁的工作原理，什么场景下会导致死锁，以及你实际遇到过没有。我有个同事，面试时被问到这个问题，他直接说“我们之前有个业务，因为间隙锁导致大量超时，后来改成 RC 级别，配合应用层逻辑解决了”。面试官听完直接给了通过，因为这说明他不光懂理论，还能在实际中权衡利弊。
还有一类题是专门用来“挖坑”的，比如“你们怎么处理数据库的跨机房灾备”。很多人一听就开始大谈异地多活、数据同步方案，但面试官其实更想知道，你的方案有没有经过真实演练。比如同步延迟了怎么办，脑裂了怎么恢复，有没有定期做切换测试。我见过一个运维，他说团队每季度做一次灾备切换演练，每次都会发现新问题，然后修复再演练。这种回答，比纸上谈兵的方案靠谱一百倍。因为数据库运维最怕的就是“看起来没问题”，真正出事时才发现备份不可用、同步断了、权限配置错了。所以面试官问这类题，就是想看你有没有“实战出真知”的意识。
我想说，数据库运维面试本质上不是考你背了多少书，而是看你有没有解决问题的思路和能力。那些经典面试题，比如“索引失效的原因”“慢查询优化”“死锁排查”，与其背答案，不如想想自己实际遇到过什么。哪怕只解决过一个小问题，只要讲清楚排查过程、决策逻辑、最终效果，就比那些背了一堆理论却没实践的人强太多。面试官也是人，他们更喜欢听真实的故事和有血有肉的经验，而不是千篇一律的标准答案。所以，别怕经验少，关键是你有没有用心思考每一个坑是怎么踩的，又是怎么爬出来的。
