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 FORMATJSON分析问题计划通过optimizer_switch调整优化器参数最后才考虑用FORCE INDEX等Hint终极方案是重构SQL或索引4. 高可用架构设计要点数据库高可用是面试的重点考察方向我参与设计过多个行业的容灾方案总结出以下实战经验。4.1 数据零丢失的代价Oracle的最大保护模式能确保数据零丢失但要求主备库必须同步提交。曾经有客户坚持要用这个模式结果因为备库网络抖动导致主库频繁挂起最终不得不改为最大性能模式。三种模式对比如下保护模式数据安全性性能影响适用场景最大保护最高极大金融核心交易最大可用高中等重要业务系统最大性能一般最小非关键业务4.2 MySQL半同步复制的陷阱MySQL的半同步复制看似平衡了安全与性能但有个隐藏坑点默认配置下只要有一个从库确认即可提交。我在互联网金融项目中就遇到过主库和从库数据不一致的情况。正确的配置姿势是SET GLOBAL rpl_semi_sync_master_wait_for_slave_count2; SET GLOBAL rpl_semi_sync_master_timeout10000; -- 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 Query6.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才解决。