数据库面试高频：容灾备份 + 索引分类 & 使用场景

一、数据库容灾备份（MySQL 为主，面试必背）

（一）备份分类

1. 按备份数据内容

（1）全量备份

整库所有数据完整导出，恢复简单，但耗 IO、耗时间，适合低峰期定期做。

（2）增量备份

仅备份上次全量 / 增量后变化的数据，体积小、速度快；恢复必须依赖全量 + 所有增量，链条断裂无法恢复。

（3）差异备份

备份上次全量之后所有变更，恢复只需要「一份全量 + 一份最新差异」，平衡速度与恢复复杂度。

2. 按备份实现方式

（1）物理备份（冷备 / 热备）

直接复制底层数据文件、日志文件，速度快，适合大数据量。

l 冷备：停机锁库复制文件，一致性高，业务中断；

l 热备：在线备份（MySQL：xtrabackup），无需停库，生产主流。

（2）逻辑备份

导出 SQL 语句（mysqldump、mysqldumpp），跨版本、跨库迁移友好；大数据量慢，恢复耗时。

3. 按日志（二进制日志 binlog）

binlog 属于增量日志备份，记录所有 DML/DDL 操作，可实现时间点恢复 (PITR)。

l 作用：数据误删找回、主从同步、审计。

（二）容灾等级（RTO/RPO 面试必问）

l RPO（恢复点目标）：故障丢失数据最多容忍多久

RPO=0：零数据丢失（同步复制）；RPO 越大丢数据越多

l RTO（恢复时间目标）：故障后业务恢复时长

RTO 越小，停机时间越短

三层容灾架构

1.本地单机房（本地备份）

定时全量 + binlog，应对误删、表损坏；机房火灾、断电会整体失效。

2.同城双活 / 主从

同城市两个机房，主库故障自动切换备库，RTO 秒级；同城自然灾害会一起故障。

3.异地多活 / 异地灾备

跨城市机房，同步 / 异步复制，城市级灾难兜底；成本高、同步延迟。

（三）MySQL 主从容灾模式

1.异步复制（默认）

主库写完直接返回客户端，binlog 异步发给从库；主宕机，已提交但未同步的数据丢失，RPO>0。

2.半同步复制（semi-sync）

主库写完，等待至少一台从库接收 binlog 后再返回；大幅降低丢数据概率，性能轻微损耗。

3.同步复制（MGR / 双活）

主从同时落盘成功才返回，RPO=0，无数据丢失，性能开销大。

（四）故障恢复流程（面试口述标准答案）

1.确认故障类型：误删表 / 磁盘损坏 / 主机宕机 / 机房故障

2.若主机宕机：切换备库（MGR、MHA 自动切换），恢复业务 RTO

3.若误删数据：

1）用全量备份恢复临时实例；

2）截取对应时间段 binlog；

3）重放 binlog 到删除前时间点；

4）导出丢失数据回灌线上库（PITR 时间点恢复）

（五）MHA / MGR 容灾方案简答

l MHA：单机中间件，监控主从，主宕机自动选最优从库提升为主，适合传统一主多从；有切换延时。

l MGR（MySQL 组复制）：集群多主架构，原生高可用，故障自动剔除节点，支持多节点写入，数据强一致。

二、索引的意义

索引是存储引擎用于快速找到数据记录的一种数据结构

（一）索引的优点

1. 极大地加快数据的检索速度

这是建立索引最核心的原因。通过索引，数据库可以跳过绝大多数无关数据，直接精准定位，将原本需要数秒甚至数分钟的查询缩短至毫秒级。

2. 显著加速表与表之间的连接（JOIN）

在多表关联查询时，MySQL 会使用驱动表的数据去匹配被驱动表。如果连接字段（如 order.user_id 和 user.id）上有索引，数据库就能通过索引快速匹配，避免执行恐怖的笛卡尔积计算。

3. 减少排序和分组的时间（ORDER BY / GROUP BY）

索引在存储时本身就是排好序的（特别是 B+ 树索引）。当你的查询包含 ORDER BY 或 GROUP BY 时，数据库可以直接利用索引的顺序返回结果，避免了在内存中进行昂贵的外部排序（Filesort），从而节省了大量的 CPU 资源。

4. 保证数据的唯一性（唯一索引）

通过创建唯一索引（Unique Index）或主键索引，数据库会在底层自动校验数据的唯一性，从数据库层面筑起一道防线，防止业务代码并发时产生脏数据。

（二）索引的缺点

索引并不是越多越好，盲目建索引会带来以下副作用：

1. 隐形的时间成本：降低增删改（DML）的效率

虽然索引让 SELECT 变快了，但它会让 INSERT、UPDATE、DELETE 变慢。

因为每次数据发生变动，数据库不仅要修改底层的数据行，还要实时维护所有的索引树（比如 B+ 树的节点分裂、合并、平衡旋转）。如果一张表建了 5、6 个索引，每次写操作的开销会成倍增加。

2. 显的空间成本：占用大量的磁盘空间

索引也是一种数据，需要持久化到磁盘上。

对于高频更新或者大字段的表，索引占用的空间甚至可能超过数据本身的大小。这不仅增加了存储成本，还会挤占数据库的内存缓冲池（Buffer Pool），间接影响整体性能。

 

3. 索引并不是万能的，存在索引失效场景

 违背最左前缀原则、字段使用函数、隐式类型转换、not in、!=、%前缀模糊 等会导致索引失效，依旧走全表扫描； 当数据筛选后返回大部分数据（比如超过表 30% 数据），优化器会放弃索引选择全表扫描。

 

三、索引分类 & 使用场景（MySQL InnoDB 核心面试）

1. 按存储结构（底层物理分类，必考）

（1）B + 树索引（默认主键 / 普通索引）

结构：叶子节点存完整行数据（主键索引）/ 主键值（二级索引），有序链表，范围查询极强。

适用场景：绝大多数业务场景

l 等值查询 where id=100

l 范围查询 where age>18 and age<30

l 排序 order by create_time

l 分组 group by status

不适合：大量重复低基数字段（性别、状态只有 2 个值）

（2）哈希索引（Memory 引擎，InnoDB 自适应哈希 AHI）

结构：哈希表，等值匹配 O (1)，无序。

适用场景：纯等值匹配

where phone='138xxxx'

缺点：不支持范围、排序、模糊查询；哈希冲突；InnoDB 不手动创建 hash 索引。

（3）全文索引 fulltext

场景：文本模糊检索，like % 关键词 % 不走普通索引

例如文章标题、内容模糊搜索：match(title) against('大数据')

限制：只支持 char/varchar/text，中文需分词插件。

（4）空间索引 SPATIAL

存储地理位置坐标（point、多边形），用于地理距离查询、范围圈选（外卖、地图业务）。

2. 按索引字段数量

单列索引

单个字段建立，简单等值、筛选查询。

联合索引（复合索引）

多个字段组合，遵循最左匹配原则

例：索引 (a,b,c)

有效：where a=? /where a=? and b=? /a=? and b=? and c=?

失效：where b=? /where c=? /where b=? and c=?

使用场景：业务多条件联合筛选，减少回表，覆盖索引优化。

3. 按索引功能（逻辑分类，面试高频）

1）主键索引 primary

唯一、非空，一张表只能一个；

InnoDB 聚集索引，叶子存整行数据；

场景：唯一标识行，关联外键、主从同步。

2）唯一索引 unique

字段值全局唯一，允许一个 null；

场景：手机号、身份证、用户账号，防止重复数据。

3）普通索引 INDEX

无唯一性约束，允许重复、null；

场景：普通筛选条件（创建时间、状态、商品分类）。

4）覆盖索引

查询字段全部包含在索引里，不需要回表，性能极高

示例：select name,price from goods where id=10

索引 (id,name,price)

场景：高频列表查询，减少 IO，千万级表优化必备。

5）前缀索引

长字符串只截取前 N 位建立索引，节约存储空间

create index idx_name on user(name(10));

场景：长邮箱、长名字，区分度足够即可使用；

缺点：不能 order by、无法用作覆盖索引完整查询。

6）自适应哈希索引 AHI（InnoDB 内置）

MySQL 自动为热点 B + 树页建立哈希缓存，加速等值查询，无需手动创建。

4. 特殊索引区分 & 使用禁忌

1.聚集索引 vs 非聚集（二级索引）

l InnoDB 主键 = 聚集索引，数据按主键排序存储；

l 二级索引叶子只存主键，查询到数据需要回表拿完整行。

2.什么情况不建索引？

l 数据量少（几百行全表扫描更快）；

l 字段基数极低（性别 0/1）；

l 频繁更新字段（索引维护成本高，锁开销大）；

l 模糊查询 % xxx 开头无索引。

面试简答汇总（直接背诵）

索引使用场景一句话版

 

 

1. B + 树索引：等值、范围、排序、分组，通用首选；

2. 联合索引：多条件查询，利用最左前缀；

3. 唯一索引：手机号、身份证等唯一性字段；

4. 覆盖索引：列表查询，避免回表优化；

5. 全文索引：文本关键词检索；

6. 哈希索引：仅纯等值匹配；

7. 前缀索引：超长字符串节省空间；

8. 空间索引：地理位置业务。

容灾备份面试高频问题预判

1. 全量、增量、差异备份区别？恢复流程差异？

2. RPO/RTO 含义，双活、异地灾备如何平衡两者？

3. binlog 作用，如何实现误删数据时间点恢复？

4. MHA 和 MGR 高可用区别，适用业务场景？

5. 物理备份和逻辑备份优缺点？什么场景选 xtrabackup/mysqldump？

 

 

 

容灾备份 5 道高频面试题标准答案（可直接背诵）

1. 全量、增量、差异备份区别？恢复流程差异？

三者定义区别

1.全量备份

完整拷贝库内所有数据、索引、日志，备份完整副本。

优点：恢复最简单；缺点：占用空间大、备份耗时长、IO 压力高。

2.增量备份

只备份上一次任意备份（全量 / 增量） 之后新增 / 修改的数据。

优点：备份速度快、体积小；缺点：备份链条长，任一增量文件损坏整体无法恢复。

3.差异备份

只备份上一次全量备份之后所有变更数据，不受中间增量影响。

优点：恢复文件少、容错性比增量高；缺点：随时间推移备份包会越来越大。

恢复流程对比

1.全量备份恢复：仅导入一份全量文件即可恢复完整数据。

2.增量备份恢复：全量备份 + 按时间顺序依次导入所有增量备份，顺序不能乱。

3.差异备份恢复：一份全量备份 + 最新一份差异备份，无需中间增量。

生产常用组合

每周一次全量 + 每日差异备份，兼顾备份速度与恢复效率。

2. RPO/RTO 含义，双活、异地灾备如何平衡两者？

RPO、RTO 概念

l RPO（恢复点目标）：灾难发生后，最多允许丢失多少数据，单位分钟 / 秒。

RPO=0：零数据丢失；数值越大，丢失数据越多。

l RTO（恢复时间目标）：故障后业务恢复正常运行的时长。

数值越小，停机时间越短，可用性越高。

同城双活对 RPO/RTO 的平衡

1.数据同步复制，RPO≈0，几乎不丢数据；

2.主节点故障自动切换，RTO 秒级；

3.短板：同一城市，地震、洪水、城市断电会双机房同时故障，无法抵御城市级灾难。

适用：金融、支付核心业务，追求低丢失、快速恢复。

异地灾备对 RPO/RTO 的平衡

1.跨城市机房，网络距离远，一般采用异步 / 半同步复制，存在数据延迟，RPO>0，会丢失少量增量数据；

2.异地切换流程复杂，需要人工 / 复杂调度，RTO 分钟～小时级；

3.优势：城市级灾难兜底，数据不会全部损毁。

适用：政企、电商兜底容灾，做长期数据兜底。

整体平衡思路

同城双活承载线上流量，保证日常故障 RPO、RTO 双低；异地机房作为兜底灾备，应对极端城市灾难，牺牲少量数据一致性换取全局数据安全。

3. binlog 作用，如何实现误删数据时间点恢复（PITR）

binlog 三大核心作用

1.主从同步：主库把 DML/DDL 写入 binlog，同步给从库保证数据一致；

2.数据恢复（PITR 时间点恢复）：记录所有修改操作，误删、误更新可找回数据；

3.数据审计：记录所有数据库变更，用于操作追溯、合规核查。

误删数据时间点完整恢复步骤

1. 找到故障前最近一次全量备份，单独搭建一台临时恢复实例；

2. 在 binlog 日志中定位误删 SQL 对应的起止时间点；

3. 截取两段 binlog：全量备份结束时间 → 删除操作之前的 binlog；

4. 将截取后的 binlog 重放至临时实例，此时数据恢复到删除前状态；

5. 导出丢失 / 被删除的数据；

6. 将导出数据回灌线上生产库，业务正常运行。

补充：不能直接在线重放 binlog，会覆盖现有正常数据，必须用临时实例隔离操作。

4. MHA 和 MGR 高可用区别，适用业务场景

1）MHA（Master High Availability）

架构：独立中间件管理一主多从原生 MySQL 复制。

特点

1. 仅单主写入，从库只读；

2. 主库宕机后 MHA 自动对比所有从库 binlog，选择数据最全的从库提升新主；

3. 切换存在 10~30 秒真空期，期间无法写入；

4. 无数据强一致保障，异步复制场景会丢少量数据；

5. 部署简单、兼容低版本 MySQL、成本低。

适用场景

中小业务、传统一主多从架构、预算有限、可接受短暂写入中断的项目。

2）MGR（MySQL Group Replication，组复制）

架构：MySQL 原生集群，分布式一致性协议 Paxos。

特点

1. 支持单主模式、多主写入模式；

2. 集群内部数据强一致，多数节点确认才提交，RPO=0；

3. 节点故障自动剔除，切换秒级，无长时间中断；

4. 自带冲突检测，多主写入自动处理事务冲突；

5. 性能开销高于 MHA，对网络稳定性要求高。

适用场景

金融支付、高并发核心交易、要求零数据丢失、高可用要求极高的大型业务。

核心对比总结

l 追求低成本、简单运维、现有主从改造 → MHA

l 核心交易、零丢数据、秒级故障转移 → MGR

5.物理备份和逻辑备份优缺点？什么场景选 xtrabackup/mysqldump？

一、物理备份（代表工具：XtraBackup）

直接拷贝磁盘上的数据文件、redo、undo、ibd、binlog 底层物理文件。

优点

1. 备份、恢复速度极快，大数据量优势明显；

2. 直接拷贝物理页，对数据库 CPU 消耗低；

3. 支持增量、差异热备，无需锁表，不阻塞线上业务。

缺点

1. 跨操作系统、跨数据库版本兼容性差；

2. 只能备份 InnoDB/MyISAM，不能单独导出单张表结构；

3. 备份文件体积大，无法直接查看 SQL。

二、逻辑备份（代表工具：mysqldump）

查询数据库，生成 INSERT、CREATE 等 SQL 语句保存。

优点

1. 跨平台、跨 MySQL 版本迁移友好；

2. 可灵活单库、单表备份，能直接编辑 SQL 文件；

3. 无需底层文件权限，部署简单。

缺点

1. 大数据量备份恢复极慢，全表读取消耗大量 CPU；

2. 备份期间会锁表 / 锁事务，高并发业务易阻塞；

3. 不支持增量备份，只能全量导出。

场景选型

选用 XtraBackup

l 几十 G / 百 GB 大库日常定时备份；

l 生产在线热备，不能停机、不能阻塞业务；

l 需要增量、差异定期备份 + 时间点恢复；

l 机房整体迁移、整库快速克隆。

选用 mysqldump

l 小库、测试环境、单表导出；

l 跨版本、跨服务器数据迁移；

l 临时导出少量数据做分析、核对；

l 快速导出建表语句、初始化脚本。