题目重点：把SQL执行节点、共享存储和故障域拆开，解释扩展读实例不等于扩展写能力。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 明确问Aurora存储架构与传统数据库区别，未指定兼容引擎、代际或部署类型。练习以官方cluster的writer/reader和跨AZ共享volume为背景，不编造内部固定quorum数字。
- 对照基线是一台计算实例管理本地数据库页、另建传统复制实例的系统；“传统数据库”不是统一实现，需说明比较对象。
解题路线
- 先拆执行SQL、管理buffer/cache、存储数据和持久化提交四项责任。Aurora cluster中计算实例与cluster volume分离，reader连接相同存储抽象；添加reader主要增加读执行能力。
- 共享存储不等于共享内存cache。各实例仍有本地缓存/执行资源，扩容reader可能有cold cache和连接路由变化；写入顺序与事务正确性不能由多个reader自然保证。
- 比较扩展与故障：compute坏了可替换/提升合适reader，存储底层有自身多AZ冗余；客户端仍需处理连接断开、重试和事务结果未知，不能把存储复制当作应用无需故障处理。
- 成本看读写IO、cache命中、容量增长和后台维护。架构分离减少资源绑死，也增加网络依赖及观测层次；按具体部署/引擎验证，不把服务名当性能证明。
手动走一遍
热点报表让writer CPU繁忙，可移到reader缓解读执行；但同一热点行每秒争抢写锁，增加reader不会减少writer上的串行冲突。writer故障后应用重建连接，并用业务幂等键确认未知支付事务。
规模与取舍
查询成本由执行计划、缓存/存储IO和网络决定，不能统一O(1)。容量讨论分开compute CPU/内存、持久存储、读实例数量和写瓶颈；读实例多不保证线性加速。
易错点与追问
容易失分的边界
- 把共享volume说成所有reader读的内存瞬时一致。
- 新增reader自动提升写事务吞吐。
- 故障自动恢复就无需应用重试/结果确认。
继续深挖
- 缓存冷启动如何影响failover后的尾延迟？
- 何时瓶颈在SQL执行而非存储IO？
技术参考
- Aurora cluster计算与存储：技术语义参考，具体题目按本文约定。
