干我们这行的都懂，数据库运维面试或者考证，光靠背理论题根本不顶用。面试官随便抛个“主从延迟怎么排查”或者“索引失效怎么定位”，你要是只会背概念，立马露馅。我这些年带团队、面人、自己也考过几个认证，攒了套题库，今天挑几个高频的真真题，把答案和解析掰开了说。咱不整虚的，直接上干货，每个题我都尽量讲清楚“为什么”而不是“是什么”，这样你理解了，考场上遇到变形题也不慌。
先来个基础但坑多的：MySQL主从复制中，如果从库的SQL线程报“SlaveSQLRunning: No”，你第一步该查什么？很多人上来就检查网络或者主库状态，其实最该先看的是里的字段。这个字段会直接告诉你具体是哪个SQL语句执行失败了，比如最常见的“Duplicate entry”或者“Table doesn't exist”。解析一下：主从同步时，从库会重放主库的binlog，如果从库表结构和主库不一致，或者主键冲突，SQL线程就会中断。这时候别急着重启复制，先修复数据一致性，比如跳过错误事务，或者手动补数据。记住，遇到这种问题，第一反应应该是“查错误日志”，而不是“重启大法”。
再聊一个性能调优的经典题：慢查询日志里发现某个SELECT语句执行时间超过10秒，表数据量500万行，索引已经建了，但查询计划显示全表扫描。怎么破？很多人会下意识加索引，但加索引前得先看输出里的字段。如果显示，说明索引没被用上。这时候要检查查询条件：比如你用了，这种左模糊匹配会导致索引失效，因为B+树索引是按前缀排序的。解决方案可以是改成，或者用全文索引。还有一个常见坑：在索引列上做函数操作，比如，索引也会失效。正确的写法是。这里的关键是“索引失效的根源在于破坏了索引的有序性”，理解了这一点，很多问题迎刃而解。
第三个题考事务隔离级别，面试官最爱问：MySQL默认隔离级别是可重复读，它在什么情况下会产生幻读？怎么解决？得明确，可重复读通过MVCC（多版本并发控制）解决了快照读下的幻读，但当前读（比如）仍然可能产生幻读。举个例子：事务A执行，返回了10行，事务B插入了一行id=11的数据并提交，然后事务A再执行同样的查询，会发现多了一行。这是因为使用了行锁和间隙锁，但间隙锁只锁住已存在的记录之间的间隙，如果新插入的记录恰好落在某个未锁定的间隙里，就会产生幻读。解决方法是把隔离级别提升到串行化，或者用时配合，但代价是并发性能下降。这个题的解析核心是“区分快照读和当前读”，很多人栽在这儿。
第四个题考备份恢复：你用mysqldump全量备份了一个100GB的数据库，凌晨2点执行，耗时1小时。结果下午3点数据库崩溃了，你只能恢复到凌晨2点的数据，那2点到3点之间的数据怎么补？这题考的是“binlog的增量恢复”。正确的做法是：备份时用选项，这样mysqldump会在备份文件中记录备份开始时刻的binlog文件名和位置（比如）。恢复时先导入全量备份，然后找到从那个位置开始到崩溃前一刻的所有binlog文件，用工具解析成SQL并执行。注意要跳过备份期间产生的binlog，因为备份文件已经包含了那些数据。这里有个细节：如果binlog文件被删了或者没开启，那就只能认栽。所以生产环境必须开启binlog，而且最好设置为7天以上。这道题的解析重点是“备份和binlog的配合使用”，而不是单纯讲命令。
第五个题考数据库连接池配置：一个Java应用，连接池用HikariCP，最大连接数设了20，但监控显示活跃连接数经常冲到18，响应时间变长。你应该调大最大连接数还是优化SQL？很多人第一反应是调大连接数，但这是典型的“头痛医头”。解析一下：如果活跃连接数接近最大值，但CPU使用率不高，说明线程在等待锁或者I/O（比如磁盘慢查询），这时候加连接只会增加上下文切换，反而让性能更差。正确的做法是先排查慢查询，看是不是有SQL锁等待或者索引缺失。比如用看有没有大量的线程，或者用看锁信息。如果确实是因为SQL优化不到位导致连接长时间占用，那调大连接数就是饮鸩止渴。这个题的解析逻辑是“连接数不是性能瓶颈的直接表现，要透过现象看本质”。
一个题考数据库高可用：你搭建了主从架构，主库挂了，用把从库提升为主库，但业务还是连不上，为什么？典型的坑是“应用层没有切换连接”。解析：数据库层面的主从切换只是把从库的角色改成了主库，但应用的数据库连接字符串还指向原来的主库IP。所以搭建高可用必须配合VIP（虚拟IP）或者DNS切换，比如用Keepalived实现VIP漂移，或者用ProxySQL、MyCat这样的中间件做读写分离和自动切换。还有个常见疏忽：从库提升为主库后，它的参数可能还是，需要手动设成，否则业务写操作会报错。这道题的解析核心是“数据库高可用不等于应用高可用，需要全链路考虑”。
这套题我反复筛过，都是实际运维中踩过的坑。你光背答案没用，得理解背后的原理。比如索引失效那道题，你懂了“左模糊匹配为什么失效”，下次遇到，自然知道怎么改。再比如主从复制错误，你懂了“SQL线程报错意味着数据不一致”，就不会傻乎乎重启。建议你把这些题当案例去分析，每个都动手在测试环境跑一遍。面试或者考证的时候，考官问的不是你记不记得命令，而是你有没有“遇到过、排查过、解决过”的经验。把这套题吃透，不仅为了通关，更是为了以后在线上少背锅。
