面试数据库运维岗位，我最怕听到的一句话是“我背了很多题”。因为面试官要的不是人形题库，而是能干活、会思考的人。今天聊的这几道高频题，是我从几十场面试里扒出来的真实案例，配上解析，目的是让你不光知道答案，还能明白背后的逻辑。
先说最基础的“MySQL主从复制延迟怎么处理”。这题几乎是必问的，但很多人上来就甩一堆参数调优，像什么“syncbinlog=1”这类。面试官其实想听的是：你遇到延迟时，第一步干什么？正确答案是：先确认延迟是不是真的存在，用“SecondsBehindMaster”这个值判断。但要注意，这个值在从库IO线程或SQL线程出问题时可能不准。更靠谱的做法是检查主库的binlog位置和从库的执行位置，或者用第三方工具如pt-heartbeat校准。延迟的原因千奇百怪：可能是主库写入压力大，从库硬件差，也可能是大事务卡住了。我记得有个案例，一个团队跑了个批量删除语句，删了100万行，结果从库追了半小时。正确的处理方式是拆成小批次，或者用pt-osc这类工具。所以，回答时要分情况：先诊断，再针对性解决。
接着聊“数据库连接池怎么配置”。这题看似简单，但坑很深。很多人说“连接数设大点就行”，结果系统崩了。面试官想考察的是你对资源管理的理解。连接池的核心不是越大越好，而是匹配业务模型。比如一个API服务，平均响应时间50毫秒，QPS是1000，那需要的连接数大约是QPS乘以平均响应时间，也就是50个左右。但实际还得考虑峰值和连接复用率。我见过一个团队把连接池设成200，结果数据库并发过高，直接OOM。正确的做法是先用压测找出数据库能承受的最大连接数，然后给连接池设一个安全阈值，比如最大连接数的70%。还要考虑连接泄漏问题，所以超时时间和最大等待队列长度也要设置。别忘了定期检测连接健康状态，用“SELECT 1”或者配置验证查询。
再来看一个容易翻车的题：“数据库CPU飙升到100%怎么排查”。这题考的是实战能力。很多人一上来就重启数据库，这是下下策。正确的步骤是：先用操作系统命令查哪个进程占CPU高，比如top或htop；然后进MySQL，用“SHOW PROCESSLIST”看哪些SQL在运行；通常会发现一堆慢查询或者锁等待。接着，针对这些SQL用EXPLAIN分析执行计划。常见原因有：没建索引、索引失效、或者数据量太大。我记得有个案例，开发写了个“SELECT FROM orders WHERE status LIKE '%pending%'”，导致全表扫描，CPU直接飙到90%。解决办法是改成“status = 'pending'”并用索引。如果一时找不到问题，可以用“performanceschema”抓取热点SQL，或者启用慢查询日志。还得考虑是不是硬件故障，比如CPU本身有问题，但概率极低。
“数据库高可用方案怎么设计”这题，面试官想听的是你对可用性和一致性的权衡。很多人张口就是“主从复制加keepalived”，但这在数据一致性要求高的场景下会出问题。比如主库崩溃时，从库可能还没同步完数据，切过去就会丢数据。更完整的方案是：根据业务容忍度选策略。金融场景用MySQL MGR（Group Replication）或者Galera Cluster，保证强一致性。互联网场景用异步复制加哨兵或MHA，允许秒级数据丢失。但要注意，哨兵只能做自动failover，不能解决数据冲突。所以生产环境通常会再加一层Proxy，比如ProxySQL或MaxScale，做读写分离和故障切换。部署时还要考虑机房分布，避免单点故障。我见过一个公司把主库放北京，从库放上海，结果网络抖动导致复制延迟，用户看到的数据不一致。他们加了半同步复制，牺牲一点性能换一致性。
“如何优化慢查询”这题，答案不能只说“加索引”。面试官要的是系统性的排查思路。第一步是定位慢查询，用慢查询日志或者performanceschema。第二步是分析SQL执行计划，看是全表扫描还是用了索引。但索引不是万能的，比如“WHERE name LIKE '%abc%'”这种模糊查询，普通索引用不上，得用全文索引或者搜索引擎。第三步是看数据量，如果单表超过千万行，即使有索引也可能慢，这时候要分库分表。我记得有个系统，一张日志表有5亿行，查询按时间范围走，但业务需求是按用户ID查。解决方案是加一个用户ID的索引，同时把历史数据归档到冷库。第四步是检查硬件，比如磁盘是不是HDD，内存够不够。还要考虑业务逻辑能否优化，比如改成“SELECT id, name FROM users”这种覆盖索引查询。
“数据库备份策略怎么制定”这题，很多人只背“全量加增量”，但面试官想问的是恢复测试。备份的本质是为了恢复，如果从没恢复过，备份就是一张废纸。策略上，核心业务建议每天一次全量备份，每6小时一次增量备份，保留30天。但要注意，全量备份不能放在业务高峰期，比如凌晨2点。备份工具也分场景：MySQL用mysqldump或XtraBackup，PostgreSQL用pgdump或pgbasebackup。更关键的是，你要定期做恢复演练，比如每个月从备份里恢复一个测试库，验证数据完整性和恢复时间。我见过一个公司，备份文件存了3年，但恢复时才发现文件损坏，因为从来没校验过。所以，备份后要跑checksum，并且异地存储一份，防止机房故障。别忘了写恢复文档，步骤详细到每个命令，因为出问题时大家都很慌。
“数据库锁的问题怎么排查”这题，面试官想看你是否理解锁的机制。很多人只会说“用SHOW ENGINE INNODB STATUS”，但不知道怎么读输出结果。更实用的方法是：先查事务表，比如“SELECT FROM informationschema.INNODBTRX”，看哪些事务在运行；再用“SHOW PROCESSLIST”确认这些事务对应的SQL。常见场景是：事务A锁住了一行数据，事务B去更新同一行，结果B被阻塞。这时候要检查事务A是不是没提交或没回滚，如果是程序bug，比如忘记在代码里提交事务，就得联系开发修复。还有更隐蔽的死锁，比如两个事务互相等待对方的锁。解决方案是：加锁顺序要一致，或者用“innodblockwaittimeout”设置超时时间。我记得有个案例，一个订单系统同时更新订单表和库存表，因为两个表的加锁顺序不一致，导致死锁频发。后来统一了加锁顺序，问题解决。
“数据库分库分表要注意什么”这题，面试官想听的是你在拆分后踩过的坑。很多人只会说“用sharding-key”，但实际复杂得多。第一步是选分片键，要选业务查询最频繁的字段，比如用户ID或订单ID。但分片键选错了，跨分片查询就会很慢。比如按用户ID分片，但业务需要按日期查所有订单，那就得建全局索引或者用Elasticsearch做辅助查询。第二步是数据迁移，不能直接停服，得用双写方案：先写新库和旧库，等数据一致后再切流。第三步是分布式事务问题，比如在多个分片里更新数据，用XA协议性能差，通常用最终一致性方案，比如本地消息表。我见过一个团队，拆分后没考虑join查询，结果业务方查关联数据时，得写大量代码聚合，开发成本飙升。所以，拆分前要先评估业务查询模式，能不分就不分，用读写分离或缓存先扛。
