1. 数据库复制机制深度解析
数据库复制是DBA面试必问的核心技术点，也是实际工作中保障数据高可用的基础。我经历过多次因为复制问题导致的线上故障，深刻理解不同数据库的复制特性差异。下面就以Oracle、MySQL、PostgreSQL三大主流数据库为例，带你掌握复制技术的精髓。
1.1 Oracle与PG的物理复制对比
Oracle的Data Guard和PG的流复制都采用物理复制机制，这种复制方式效率极高。简单来说，就像复印机一样直接把数据块的变更原样复制到备库。我在金融行业做核心系统迁移时，就靠物理复制实现了TB级数据的零停机迁移。
具体实现上，Oracle通过LGWR进程传送redo日志，经过RFS接收后由MRP进程应用。PG则是walsender传送WAL日志，walreceiver接收后由startup进程恢复。有趣的是，Oracle有个独特功能：通过配置fal_server参数，可以让备库主动拉取日志，这个特性在跨机房部署时特别实用。
1.2 MySQL的另类逻辑复制
MySQL的复制机制堪称数据库界的"异类"。虽然InnoDB也有redo日志，但主从复制却走的是binlog这条逻辑日志路径。这就好比别人都用快递寄原箱物品，MySQL非要拆箱后寄零件清单。
主库的dump线程传送binlog到从库后，IO线程写入relay log，再由SQL线程重放。这种设计带来一个典型问题：当主库大量并发写入时，从库单线程重放会成为瓶颈。我在电商大促时就遇到过从库延迟数小时的情况，最后通过启用多线程复制(MTS)才解决。
2. 索引背后的数据结构艺术
索引是数据库性能的命脉，也是面试官最爱深挖的技术点。记得有次面试，技术总监让我在白板上手绘B+树结构，还要求对比不同数据库的索引实现差异。
2.1 B+树的精妙设计
所有数据库都使用B+树索引，但实现方式各有千秋。MySQL的聚簇索引就像图书馆按照ISBN号排架，数据本身就是索引。而Oracle的堆表+索引组合，则像图书馆先按到馆顺序存放图书，再单独维护ISBN目录。
特别要注意的是MySQL的二级索引寻址需要两次查找：先通过二级索引找到主键，再回聚簇索引找数据。这就解释了为什么阿里规范强制要求"禁止使用SELECT *"——减少回表操作能显著提升性能。
2.2 索引扫描的三种姿势
- 索引全扫描：沿着B+树的叶子节点链表顺序读取，适合范围查询。就像按字母顺序翻阅字典，虽然要读很多页，但不用来回跳转。
- 索引快速全扫描：直接物理读取索引段，类似把字典页撕下来一次性扫描。速度快但不保证顺序，适合统计场景。
- 索引跳跃扫描：当SQL缺少前导列时，就像查字典时不按首字母直接翻内页，效率往往惨不忍睹。我在优化ERP系统时就遇到过这类问题，通过调整索引列顺序使查询性能提升百倍。
3. 执行计划绑定实战技巧
执行计划稳定性直接影响系统性能，我在银行系统维护中就遇到过因为执行计划突变导致批量作业超时的生产事件。
3.1 Oracle的SPM魔法
Oracle的SQL Plan Management(SPM)就像给执行计划上保险。通过DBMS_SPM包可以捕获、验证和固定执行计划。具体操作：
-- 捕获执行计划 DECLARE l_plans_loaded PLS_INTEGER; BEGIN l_plans_loaded := DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE( sql_id => 'g54u9m9s4b3a8'); END; / -- 固定执行计划 EXEC DBMS_SPM.ALTER_SQL_PLAN_BASELINE( sql_handle => 'SYS_SQL_7b76323ad90440b9', plan_name => 'SYS_SQL_PLAN_d90440b9b65c5c5d', attribute_name => 'FIXED', attribute_value => 'YES');3.2 MySQL的Hint困境
MySQL缺乏原生执行计划绑定功能，只能靠Hint临时干预。但Hint就像强心针，用多了系统反而更脆弱。我的经验是：
- 先用
EXPLAIN FORMAT=JSON分析问题计划 - 通过
optimizer_switch调整优化器参数 - 最后才考虑用
FORCE INDEX等Hint - 终极方案是重构SQL或索引
4. 高可用架构设计要点
数据库高可用是面试的重点考察方向，我参与设计过多个行业的容灾方案，总结出以下实战经验。
4.1 数据零丢失的代价
Oracle的最大保护模式能确保数据零丢失，但要求主备库必须同步提交。曾经有客户坚持要用这个模式，结果因为备库网络抖动导致主库频繁挂起，最终不得不改为最大性能模式。三种模式对比如下：
| 保护模式 | 数据安全性 | 性能影响 | 适用场景 |
|---|---|---|---|
| 最大保护 | 最高 | 极大 | 金融核心交易 |
| 最大可用 | 高 | 中等 | 重要业务系统 |
| 最大性能 | 一般 | 最小 | 非关键业务 |
4.2 MySQL半同步复制的陷阱
MySQL的半同步复制看似平衡了安全与性能，但有个隐藏坑点：默认配置下只要有一个从库确认即可提交。我在互联网金融项目中就遇到过主库和从库数据不一致的情况。正确的配置姿势是：
SET GLOBAL rpl_semi_sync_master_wait_for_slave_count=2; SET GLOBAL rpl_semi_sync_master_timeout=10000; -- 10秒超时5. 备份恢复的魔鬼细节
备份是DBA的最后防线，但很多面试者对其原理一知半解。我有次面试候选人时，发现他连热备的一致性原理都说不清楚。
5.1 热备的一致性实现
Oracle的热备依赖SCN机制，就像给数据库拍视频时打时间戳。恢复时通过归档日志"倒带"到一致点。具体命令示例：
RMAN> BACKUP AS COPY DATABASE PLUS ARCHIVELOG; RMAN> RECOVER DATABASE UNTIL SCN 1234567;5.2 XtraBackup的锁平衡术
MySQL的XtraBackup在备份时要获取FLUSH TABLES WITH READ LOCK，这个锁就像按下暂停键。通过以下方法可以减少锁时间：
- 提前执行
FLUSH TABLES减少脏页 - 避免使用MyISAM表
- 控制长事务
- 优化数据字典大小
6. 事务隔离的幕后英雄
MVCC机制让数据库在并发和性能间取得平衡，不同数据库的实现方式却大相径庭。
6.1 Oracle的undo魔术
Oracle通过undo段构造数据前镜像，就像给每个事务配了专属时光机。这种设计带来两个特性：
- 读不阻塞写
- 可以查询历史数据（Flashback Query）
6.2 PostgreSQL的元组版本
PG直接在元组中记录xmin/xmax，就像给每行数据贴了有效期的便利贴。这种设计虽然节省了undo空间，但需要定期vacuum清理"过期"数据。我处理过最夸张的案例是一个表膨胀到原大小的10倍，就是因为autovacuum没配置好。
7. 性能优化实战案例
7.1 解析过程优化
Oracle的软软解析能极大提升OLTP性能，关键是要用好绑定变量。我曾将某系统的硬解析比例从30%降到1%，TPS直接翻倍。监控方法：
SELECT name, value FROM v$sysstat WHERE name LIKE 'parse%';7.2 InnoDB缓冲池调优
MySQL的innodb_buffer_pool_size应该设置为可用内存的70-80%。但更关键的是监控命中率：
SHOW ENGINE INNODB STATUS\G ... Buffer pool hit rate 1000 / 10008. Redis在数据库架构中的角色
虽然Redis不是传统关系型数据库，但现代架构中经常与数据库配合使用。
8.1 持久化策略选择
RDB适合做冷备，AOF保证数据安全。我在游戏行业的最佳实践是：
- 主库关闭持久化
- 从库开启AOF每秒刷盘
- 每天定时做RDB快照
8.2 集群管理要点
Redis集群扩容时要注意slot迁移对大key的影响。曾经因为一个10MB的hash键导致集群迁移卡死，最后只能用--cluster-slots手动分配slot才解决。
