DBA 面试常见数据库原理题解析

dbaai

DBA 面试常见数据库原理题解析

一、具体问题

很多同学在准备 DBA / 数据库开发岗面试时，背了一堆命令，却答不好"为什么"。面试官真正想听的，是你对底层原理的理解，而不是"我会敲这个命令"。本文挑 4 道高频原理题，逐题给出"答到点上的思路 + 可落地的验证动作"，让你既能说清原理，也能当场证明自己动手过。

二、核心原理逐题拆解

1. 事务的 ACID 到底靠什么落地？

这是必问题。很多人只能背出四个字母，答不出实现机制，当场减分。

• 原子性(A)：靠 undo log。InnoDB 在改数据前先记"修改前镜像"到 undo，回滚就按镜像反向写回去。
  
• 一致性(C)：靠约束（主键 / 唯一 / 外键）+ 应用逻辑共同保证，数据库只兜底结构约束。
  
• 隔离性(I)：靠锁 + MVCC。普通 SELECT 走快照读，不阻塞写也不被写阻塞；只有 FOR UPDATE 这类当前读才抢锁。
  
• 持久性(D)：靠 redo log（WAL 先写日志），提交即落盘，断电不丢已提交数据。
  

面试官常追问："MVCC 怎么能读不加锁？"——答：每行有隐藏事务 id 和回滚指针，ReadView 决定你看哪个版本，所以快照读互不阻塞。

2. 为什么索引多用 B+ 树而不是哈希表或二叉树？

• 哈希表只能等值查询，不支持范围（BETWEEN、>、ORDER BY），而业务里范围查询极多。
  
• 二叉树（AVL / 红黑）在有序插入时容易退化成链表，且高度不可控；B+ 树所有数据都在叶子节点，且叶子之间用链表串起来，范围扫描一次顺序读到底。
  
• B+ 树一个节点存多个 key，三层就能撑住千万级数据，IO 次数稳定可控。
  

3. 主从复制是怎么保证"从库跟得上主库"的？

以 MySQL 为例：主库把变更写 binlog → 从库 IO 线程拉 binlog 存成 relay log → SQL 线程重放。追问点：延迟怎么排查？看 Seconds_Behind_Master，大事务、从库单线程重放、网络抖动都会拖慢；MySQL 5.7+ 可开并行复制（slave_parallel_workers）缓解。

4. 死锁是怎么产生的，怎么排查？

两个事务各自持有一把锁、又互相等对方的锁，就成环。排查：InnoDB 提供 SHOW ENGINE INNODB STATUS 的 LATEST DETECTION 段，能直接看到死锁的两个事务和各自持有的锁；根治靠统一加锁顺序、缩短事务、降低隔离级别到 RC。

三、实例参考（动手步骤）

下面给出"证明你真动手过"的可照做动作，面试前在测试库跑一遍最有底气。

1) 验证 MVCC 快照读不阻塞写（MySQL）：

2. -- 会话A
3. START TRANSACTION;
4. SELECT * FROM account WHERE id=1;   -- 快照读，读到旧值
5. -- 会话B 同时执行: UPDATE account SET balance=balance+100 WHERE id=1; COMMIT;
6. -- 会话A 再 SELECT 一次，仍是事务开始时的旧值（RR 下）
7. SELECT * FROM account WHERE id=1;
8. COMMIT;

复制代码

2) 观察主从延迟：

2. SHOW SLAVE STATUS\G
3. -- 关注 Seconds_Behind_Master、Slave_SQL_Running、Last_Error

复制代码

3) 触发并捕获一次死锁（两个会话交叉更新）：

2. -- 会话A: UPDATE t SET v=1 WHERE id=1;   -- 持 id=1 锁
3. -- 会话B: UPDATE t SET v=1 WHERE id=2;   -- 持 id=2 锁
4. -- 会话A: UPDATE t SET v=1 WHERE id=2;   -- 等 B 的锁
5. -- 会话B: UPDATE t SET v=1 WHERE id=1;   -- 等 A 的锁 → 死锁，一方被回滚
6. SHOW ENGINE INNODB STATUS\G            -- 看 LATEST DETECTION 段

复制代码

4) 前后对比：死锁发生前两个事务都能各自提交；加上"统一按 id 升序加锁"后，等待环被打破，不再互等。把这条改动前后各跑一次，现象差异一目了然。

四、实操检查清单

• 能不背字母、用"实现机制"解释 ACID 四要素（undo / 约束 / 锁+MVCC / redo）。
  
• 能说清 B+ 树相比哈希、二叉树的优势，尤其是"范围查询"和"稳定 IO"两点。
  
• 主从复制三步走（binlog → relay log → 重放）能脱稿讲，且知道延迟排查看 Seconds_Behind_Master。
  
• 死锁排查会看 SHOW ENGINE INNODB STATUS 的 LATEST DETECTION，并知道"统一加锁顺序"是根治手段。
  
• 面试前在测试库亲手跑过上面三段 SQL，确保现象和回答一致，而不是只背结论。
  
• 准备 1~2 个自己踩过的真实故障案例（如长事务拖垮库、大事务导致主从延迟），比纯原理更打动人。