📚 课程目录第3章数据库内核核心知识点高频问答（二）

事务与并发控制高频问题

事务与并发控制是数据库内核最核心也最复杂的领域。面试官常通过这类问题考察候选人对事务实现、隔离性保证、性能权衡的理解深度。回答时切忌只背诵概念，需从实现机制、取舍策略、实际案例三个层次展开。

✨ 加分原则：从“理论定义”跃迁到“实现路径”，再用“产品对比”兜底，展现系统化思维。

考察点	事务四大特性的实现机制理解，能否区分逻辑保证与物理保证
回答框架	分层回答：原子性（Undo日志实现回滚）→ 一致性（应用约束 + DB完整性检查）→ 隔离性（锁或MVCC）→ 持久性（Redo日志 + WAL刷盘）。重点突出WAL是持久性核心。
示例回答	ACID在内核中通过不同机制保证：原子性依赖Undo日志实现回滚；一致性由应用约束和DB完整性共同保证；隔离性通过MVCC或两阶段锁实现；持久性依赖Redo日志和WAL协议，确保提交事务的修改不丢失。
可能追问	① Undo日志与Redo日志在系统崩溃恢复时如何协作？② WAL日志刷盘策略有哪些（每次提交刷盘 / 组提交）？
避坑提醒	⚠️ 不要只背诵ACID定义，必须说出具体实现组件和流程。注意区分Undo（回滚）与Redo（重做）的角色，避免混淆。

考察点	对MVCC版本链、ReadView生成时机的理解程度
回答框架	MVCC通过多版本 + ReadView实现隔离。可重复读在事务首次读时生成ReadView，整个事务复用；读已提交每条SQL都生成新ReadView。关键区别：前者不会看到其他事务新提交的数据，后者会。
示例回答	MVCC通过版本链和ReadView实现隔离。可重复读在事务第一次读取时生成ReadView并复用，避免不可重复读；读已提交每条SQL都生成新ReadView，能读到其他事务已提交的最新数据。核心差异在于ReadView生成时机不同。
可能追问	① MVCC下写写冲突如何解决？（仍需要行锁或意向锁）② 快照过旧（snapshot too old）问题如何避免？
避坑提醒	⚠️ 不要误认为MVCC完全不需要锁，写写冲突仍需行锁或间隙锁。同时注意区分ReadView的生成时机与可见性判断规则。

考察点	对锁机制、死锁处理策略及工程权衡的理解
回答框架	三种策略：预防（加锁顺序、锁超时、等待-死亡）— 实现简单但可能误杀；检测（等待图 + 定期检测环路）— 准确但有延迟和回滚开销；避免（银行家算法）— 理论可行但实际少用。内核常用混合策略。
示例回答	死锁处理常用预防与检测结合。预防通过锁超时或加锁顺序规则避免死锁；检测通过维护等待图定期查找环路，选择回滚代价最小的事务。MySQL InnoDB采用等待图检测 + 事务超时机制。
可能追问	① 如何选择回滚代价最小的事务？（事务大小、锁持有数量、已执行时长等）② 分布式数据库死锁与单机死锁处理有何不同？
避坑提醒	⚠️ 不要只说一种策略，要体现对不同策略优劣的权衡。避免忽略实际产品中的实现选择（如InnoDB、PostgreSQL、OceanBase的差异）。

💡 面试官常通过追问“为什么选这个不选那个”来考察工程思维，回答时需要明确说清楚性能、复杂度、一致性三者之间的权衡关系。

📘 各公司侧重点速览：
• 字节/美团：侧重MVCC隔离级别实现细节、乐观锁与悲观锁场景选择
• 阿里/蚂蚁：侧重分布式事务（XA/TCC/Saga）、全局死锁检测
• 腾讯/华为：侧重WAL优化、组提交、崩溃恢复性能
• PingCAP/OceanBase：侧重MVCC垃圾回收、乐观事务冲突处理

🚨 面试扣分点警示：
1. 只背定义不谈实现 → 显得纸上谈兵
2. 忽略工程权衡 → 显得缺乏实战视角
3. 未提及该产品实际方案 → 显得知识面窄
建议每个问题最后都落到“在XX产品中是这样做的”