你刷到过数据库运维工程师的考题吗？说实话，我一开始觉得这玩意儿不就是背背命令、记记参数嘛，结果翻了几道真题，冷汗都出来了。今天咱们就来聊聊这事儿，顺便考考你自己——要是真坐在考场里，能答对几道？
第一道题就挺狠的：给你一张用户表，里面有几百万条数据，现在要查某个城市的所有用户，但那个城市的索引没建好。问你怎么优化这个查询，既要快，又不能锁表太久。你可能第一反应是加索引，但考点是“在线创建索引”和“业务低峰期操作”的权衡。真干过运维的都知道，生产环境加索引可不是闹着玩的，锁表几小时，业务投诉电话能打爆。这时候你得考虑用 pt-online-schema-change 这类工具，或者数据库自带的在线 DDL 功能。要是答不出来，说明你离实战还有距离。
第二道题更扎心：主从复制延迟了，从库数据落后主库十分钟，现在有一个紧急查询必须读从库，但数据不准。问你怎么处理。很多人会想当然地说“切换主库”，但实际情况是——业务高峰期你敢切？切了还得考虑连接池、事务回滚、数据一致性。正确的思路是：先判断延迟原因，是网络带宽不够还是从库负载过高。然后的临时方案是让读请求走主库，或者使用半同步复制保证数据及时。如果只回答“重启从库”，基本就凉了。
第三道题考的是备份恢复。给你一个 200 GB 的数据库，要求每天全量备份，但磁盘空间只够存三天的备份。问你怎么设计备份策略。新手会说“压缩备份”，但压缩率有限，而且恢复时间会变长。老手会想：为什么不用增量备份？为什么不用备份到远程对象存储？更关键的是，题目还加了个条件——恢复时间必须控制在 4 小时内。这时候你就得算账——全量备份恢复要 3 小时，增量备份恢复要 1.5 小时，但增量备份依赖前一天的备份文件。真正的答案是：每周做一次全量，每天做增量，并定期把全量备份上传到云存储。若没考虑恢复时间，答案就不成立。
第四道题是监控报警。给你一个数据库，CPU 使用率突然飙到 90%，但慢查询日志里一条慢 SQL 都没有。问你怎么排查。很多人会懵，因为常规思路是先看慢查询。但实际中，CPU 高可能是并发连接数太多、内存交换频繁，甚至是磁盘 I/O 瓶颈导致 CPU 等待。你得先看系统指标：连接数、磁盘队列长度、内存使用率。随后发现是连接数爆了——原来有个应用没有写连接池，每次查询都新建连接。这时候该做的不是优化 SQL，而是限制最大连接数，让开发改代码。这道题考的是能否跳出“SQL 优化”的思维定式。
第五道题是数据迁移。要把一个 Oracle 数据库迁移到 MySQL，表结构要转换，数据量有 10 TB。问你怎么做才能保证数据不丢、不停机。这题太现实，很多公司都在干这事儿。新手会说“用工具导出导入”，但 10 TB 的数据，导出要一天，导入又要一天，中间业务怎么办？老手会想：先做全量迁移，然后开启增量同步，切流量。但关键是 Oracle 和 MySQL 的数据类型不一样，例如 Oracle 的 NUMBER 到 MySQL 可能变成 DECIMAL，精度会不匹配。还有 Oracle 的序列和 MySQL 的自增 ID，迁移后 ID 可能乱。你需要提前做数据校验，用脚本对比源库和目标库的行数、校验和。少做一步，上线后数据对不上就会变成事故。
第六道题是安全相关的。突然发现数据库里有个表的数据被删了，但日志显示是正常用户操作的。问你怎么查。这题考的是审计能力。你得先查 binlog，看看是谁在什么时间执行了 DELETE。若 binlog 没开，或者只保留了一天，就很难追溯。更可怕的是，攻击者可能用了 SQL 注入，但日志里显示的是正常语句，你怎么区分？这时候可以通过执行频率判断——正常用户不会在凌晨三点批量删数据。题目还问怎么预防，答案应包括：开启审计日志、细化高危操作权限、用存储过程或视图代替直接 DML，做到最小权限原则。仅说“加强权限管理”太笼统。
第七道题是性能调优。给你一个查询跑了 30 秒，EXPLAIN 显示走全表扫描，但表里已经有索引了。问你怎么优化。这题很经典，原因可能是索引失效。比如使用函数（WHERE DATE(create_time)=‘2023-01-01’），或者隐式类型转换（WHERE id=‘123’），亦或是索引列上有 NULL 值。更常见的是，索引是复合索引，而查询条件只用了第二个字段，导致索引失效。此时你可以重建合适的索引，或调整查询条件的顺序，使最左前缀得到利用。直接说“加索引”容易掉坑。
第八道题是灾难恢复。机房断电，数据库启动不了，报错说数据文件损坏。问你怎么恢复。这题考的是备份的可用性。首先要检查是否有归档日志，判断是否需要做介质恢复。若没有备份，只能靠第三方工具抢救，成功率很低。题目还进一步问：如果备份文件也坏了怎么办？这时需要考虑跨机房备份、异地容灾。仅说“定期备份”不够，真正的答案是：备份后要做恢复演练，验证备份文件可用，且至少保留两份异地备份。
你看完这几道题，心里有底吗？说实话，数据库运维这行，光会敲 SQL 命令远远不够。真正的考题考的是你在生产环境里踩过多少坑，解决过多少实际问题。那些看似简单的题目，背后都是血泪教训。下次面试或考试前，别光刷题，多想想“如果是我，我会怎么处理”。毕竟，数据库崩了，可没人给你重来的机会。
