前几天有个读者在后台问我，说自己在准备运维工程师的面试，数据库这块总感觉心里没底，不知道面试官到底会问什么。这让我想起自己当年面试的经历，背了一堆理论，结果面试官问了个“数据库突然变慢，你怎么排查”，直接把我问懵了。其实面试题表面考知识点，深层考的是解决实际问题的能力。数据库是系统的核心，稍有异常业务就会停摆，面试官自然想看看你平时是怎么应对这些突发状况的。今天，我就把这些年积累的面试经验和对数据库的理解，揉碎了跟大家聊聊。
先说最基础但最要命的：索引。面试官最爱问“索引为什么能提高查询速度”，但别只回答 B+树这种标准答案。你要能说出具体场景，比如一张几百万行的用户表，按用户名查询时没有索引会全表扫描，每行都要读，磁盘 I/O 就上去了；有了索引，你可以在 B+树里通过二分查找快速定位，几次磁盘 I/O 就搞定。但索引不是万能的，面试官会接着问“哪些情况索引会失效”。你得举真实例子：在 WHERE 条件里对索引列用了函数，如 ，索引直接失效；或者用了 这种前缀模糊匹配，索引也废了。还有联合索引的左前缀原则，如果建的索引是 ，但查询条件只用了 b 和 c，那就只能全表扫。这些细节能让面试官知道你平时踩过坑，而不是只会背书。
再说 SQL 优化。面试官会甩出一个慢查询，问你怎么办。别一上来就说加索引，得先看执行计划。比如在 MySQL 里用 ，观察 type 列是 ALL、range 还是 ref，rows 列估算的扫描行数。有个经典案例：某查询跑了 10 秒， 显示 type 为 ALL，rows 为 80 万，但实际只返回 10 条数据。这时要分析，是不是 WHERE 条件没走索引，或者 JOIN 时驱动表选错了。子查询和 JOIN 的性能差异也要了解，很多人以为子查询一定慢，但在结果集很小、能走索引的情况下，子查询反而更快。面试官问这些，其实想知道你平时有没有动手分析慢查询日志，是否会用 抓长事务。这些实操经验比背一百条优化原则更有说服力。
事务和隔离级别是必考项，但别只背四种隔离级别的定义。面试官会问“你在实际项目中遇到过脏读或幻读吗？”你需要给出具体业务场景。比如在订单系统里，用户下单后要扣库存，如果使用读未提交级别，A 事务还没提交，B 事务就读到了扣减后的库存，而 A 回滚后 B 就拿到了假数据。幻读更坑：在可重复读级别下查询订单总数，同一个事务内两次查询结果不一样，因为其他事务插入了新订单。这时要说明 MySQL 用间隙锁和临键锁来防止幻读，而不是单纯的行锁。面试官还可能追问“如果线上库默认是不可重复读，你怎么保证数据一致性？”这就涉及加锁或乐观锁，例如在更新库存时使用 加排他锁，防止并发修改。场景越具体，面试官越觉得你靠谱。
备份和恢复这块，面试官会问“你做过数据库备份吗？怎么保证数据不丢？”很多人只说用 ，但面试官想听策略。比如负责的库有 500 GB 数据，业务要求恢复点目标（RPO）在 5 分钟以内，那么全量备份加 binlog 增量备份就是标配。全量备份每周一次，每天做差异备份，并把 binlog 实时同步到远程。恢复时，先恢复全量，再恢复差异，最后应用 binlog 到故障时刻。这里有个坑：如果 binlog 没开启或已过期，恢复就会断档，所以要检查 参数是否打开， 设置多久清理。大库建议用 XtraBackup 做物理备份，小库用 逻辑备份更方便。面试官看到这些细节，就知道你真的上线干过活。
高可用和读写分离是面试重灾区。面试官会问“你怎么实现 MySQL 高可用？”别只说主从复制，还要说清楚配置细节。比如使用主从异步复制，主库写 binlog，从库拉取后写 relay log 再回放。但异步复制有延迟，主库挂了可能丢数据，所以要考虑半同步复制，让主库等至少一个从库确认收到 binlog 后才提交。面试官还会问“主库宕机后怎么手动切换？”你需要把步骤说出来：先检查从库的 是否归零，然后把备库设为可写，修改业务连接配置。更靠谱的做法是使用 MHA、Orchestrator 等自动化工具，自动检测故障并选举新主库。读写分离也要讲实践，例如使用 Mycat、ProxySQL 等中间件，在应用层或代理层把读请求路由到从库，写请求走主库。但要注意从库延迟会导致数据不一致，比如用户刚注册完再查询可能查不到，这时可以强制读主库或等从库同步。
安全这块容易被忽略，但面试官会突然问“你怎么防止数据库被攻击？”别只回答改端口、限制 IP 这种基础操作。要说出具体做法：连接层使用 SSL 加密，防止中间人攻击；权限上遵循最小原则，应用账号只授予 ，不授予 或 ；定期审计慢查询日志，留意是否有全表扫描的恶意查询。SQL 注入要说明使用参数化查询或预处理语句，例如 Python 中 ，把用户输入当参数传而不是拼接字符串。密码管理同样重要，别把密码硬编码在配置文件里，使用 Vault、KMS 等密钥管理服务，或至少放在环境变量里。面试官听到这些细节，就会认为你的安全意识很强。
说说数据库的日常监控和调优。面试官会问“你平时怎么监控数据库性能？”别只说用 Top 或 Zabbix，要具体到指标。比如 QPS、TPS 看吞吐量；慢查询数量、峰值时间段；连接数是否接近 ；InnoDB 缓冲池命中率，低于 99% 说明内存不足；磁盘 I/O 的 iowait、await 持续偏高，可能是索引缺失或磁盘瓶颈。调优是系统工程，例如把 调到物理内存的 70%‑80%，但不要超过实际内存； 适当加大以减少刷盘频率； 直接关闭，因为 MySQL 8.0 已废弃。最好能举个案例：某库的 TPS 从 2000 降到 800，经过 发现大量行锁冲突，随后拆分大事务、优化索引，TPS 恢复到 1800，这样的经历最有说服力。
说了这么多，其实面试题背后只有一个逻辑：你平时怎么干活，面试就怎么回答。别想着临时抱佛脚背答案，数据库这东西，没踩过坑、没解决过线上问题，光靠理论是过不去的。面试官大多也有运维经历，你讲真话还是套话，他们一听就能分辨。所以建议平时多动手，多查看慢查询日志，多复盘线上事故，把这些经历整理成自己的案例库。下次面试官再问“数据库变慢怎么排查”，你就能脱口而出：先看慢查询日志，再检查连接数和锁，分析索引和参数。这样接地气的回答，比任何标准答案都管用。
