日志、主从复制与分库分表
081 binlog 的主要用途是？
难度： 基础
- A. 记录数据库变更，用于主从复制与基于时间点的恢复
- B. 记录查询日志用于慢 SQL 审计
- C. 保存行的旧版本供回滚
- D. 缓存热点数据提升读性能
查看答案与解析
正确答案A
正确原因： binlog 是逻辑日志，记录数据变更事件，支撑复制与时间点恢复。
关键边界： binlog 不记录 SELECT，redo 与 undo 属于 InnoDB 层。
错误选项辨析： 慢查询用慢日志，回滚用 undo log，读性能靠缓冲池与索引。
082 binlog 的三种格式是？
难度： 基础
- A. STATEMENT、ROW、MIXED
- B. TEXT、BINARY、JSON
- C. FULL、PARTIAL、NONE
- D. LOG、DATA、INDEX
查看答案与解析
正确答案A
正确原因： STATEMENT 记录 SQL，ROW 记录行变更，MIXED 由服务器自动选择。
关键边界： MySQL 8.0 默认使用 ROW 格式，安全性与一致性最好。
错误选项辨析： 三种错误选项都是编造的组合，不是官方支持的 binlog 格式。
083 传统主从复制（异步）的基本流程是？
难度： 基础
- A. 从库直接读取主库的数据文件
- B. 主库写 binlog，从库 I/O 线程拉取写 relay log，SQL 线程回放
- C. 主库把内存数据页复制给从库
- D. 从库定期全量导入主库备份
查看答案与解析
正确答案B
正确原因： 复制由 binlog、relay log 与 SQL 线程三段完成，I/O 线程与 SQL 线程解耦。
关键边界： 延迟源于 I/O 拉取与 SQL 回放之间的进度差。
错误选项辨析： 从库不读主库文件，不复制内存页，全量导入只是初始化方式。
084 半同步复制（Semisync）相比异步复制？
难度： 基础
- A. 所有从库同步执行每条 SQL 后才返回
- B. 至少一个从库确认收到 binlog 后主库才提交，减少丢失窗口
- C. 完全不等待从库，提交更快
- D. 从库自动变为只读主库
查看答案与解析
正确答案B
正确原因： 半同步要求至少一个从库 ACK 才提交，显著缩小故障丢失窗口。
关键边界： 从库无响应超时后可能降级为异步，且影响主库写入可用性。
错误选项辨析： 它不要求从库执行 SQL，不是完全不等待，也不会自动切换主库。
085 读写分离架构的前提与风险是？
难度： 基础
- A. 所有读都必须走从库才安全
- B. 读写分离可以消除主库压力且零延迟
- C. 读多写少且可容忍短时复制延迟；强一致读需路由到主库
- D. 从库数据永远与主库一致
查看答案与解析
正确答案C
正确原因： 从库数据由复制异步同步，存在延迟，业务需区分实时读与弱一致读。
关键边界： 强一致场景（如下单后读余额）应强制走主库。
错误选项辨析： 读从库不必然安全，延迟无法归零，从库不是实时一致。
086 主从复制延迟的常见原因是？
难度： 基础
- A. 主库 CPU 占用为 0 时延迟自动消失
- B. 网络带宽越大延迟必然为 0
- C. 从库回放并行度不足、大事务、慢 SQL、从库负载高
- D. 延迟只与 binlog 格式有关
查看答案与解析
正确答案C
正确原因： 延迟本质是回放进度落后，单线程瓶颈、大事务与从库负载都会加剧。
关键边界： 8.0 从库并行复制可缓解单线程回放瓶颈。
错误选项辨析： 主库空闲不等于无延迟，带宽不是唯一因素，格式影响有限。
087 GTID 复制相比传统基于文件名和位置的复制？
难度： 进阶
- A. GTID 只适用于单机，不支持复制
- B. GTID 复制必须全量重传所有历史事务
- C. GTID 会禁用 binlog
- D. 用全局事务标识自动定位复制起点，无需手工指定 binlog 文件与位置
查看答案与解析
正确答案D
正确原因： GTID 由源标识与事务序号组成，天然去重并自动定位，切换更简单。
关键边界： MySQL 8.0 默认开启 GTID，仍需正确配置复制账号与过滤规则。
错误选项辨析： GTID 专为复制设计，不要求全量重传，且依赖 binlog。
088 binlog 与 redo log 的关键区别是？
难度： 进阶
- A. 两者完全相同，可以互相替代
- B. binlog 属于 InnoDB 引擎内部
- C. redo log 用于主从复制
- D. redo 是 InnoDB 物理重做日志（崩溃恢复）；binlog 是 Server 层逻辑日志（复制与恢复）
查看答案与解析
正确答案D
正确原因： redo 循环写、记录页修改，服务崩溃恢复；binlog 追加写、记录事务变更，服务复制与时间点恢复。
关键边界： 两阶段提交协调两份日志的一致性。
错误选项辨析： 两者不可替代，binlog 在 Server 层，redo 不用于复制。
089 分库分表（水平拆分）的目的是？
难度： 基础
- A. 把数据按分片键分散到多库多表，突破单机容量与写入瓶颈
- B. 让所有查询都变快，无需考虑分片键
- C. 把表结构字段拆到多张表
- D. 替代所有索引与缓存
查看答案与解析
正确答案A
正确原因： 水平拆分按行分散数据，解决单机容量与写入压力。
关键边界： 跨分片查询、聚合与事务复杂度会上升，需在架构上规划。
错误选项辨析： 拆字段是垂直拆分，分片不保证所有查询更快，也不替代索引缓存。
090 选择分片键（sharding key）的原则是？
难度： 进阶
- A. 高频查询能带上的、分布均匀的、业务稳定的列
- B. 任意一列都可以，选择与查询无关
- C. 数据越集中越好，方便热点管理
- D. 分片键必须是可以为 NULL 的列
查看答案与解析
正确答案A
正确原因： 不带分片键的查询需要广播到所有分片，分布不均会形成倾斜与热点。
关键边界： 分片键一旦确定很难变更，必须业务稳定。
错误选项辨析： 分片键与查询强相关，集中分布是坏事，NULL 键会破坏路由。
091 雪花算法（Snowflake）生成分布式 ID 的特点是？
难度： 进阶
- A. 完全随机，无法按时间排序
- B. 由时间戳、机器标识与序列号组合，趋势递增且全局唯一
- C. 依赖数据库自增，每台机器共享同一计数器
- D. 只能生成 32 位短整数
查看答案与解析
正确答案B
正确原因： 雪花 ID 高位是时间戳，低位是机器与序列号，趋势递增且全局唯一。
关键边界： 需要注意时钟回拨问题，以及 64 位长度的存储与展示处理。
错误选项辨析： 它不随机、不依赖数据库，生成 64 位整数而非 32 位。
092 分库后，跨分片的 JOIN 与聚合通常如何处理？
难度： 进阶
- A. 数据库会自动在分片间执行分布式 JOIN
- B. 由应用层多次查询后内存聚合，或用中间件、宽表冗余解决
- C. 分片后 JOIN 永远免费，无任何限制
- D. 只能放弃全部查询，改为全量导出
查看答案与解析
正确答案B
正确原因： 数据分散后单库 JOIN 无法覆盖，需要应用聚合或中间件支持。
关键边界： 中间件方案支持有限跨分片操作，但代价与复杂度明显。
错误选项辨析： 跨分片 JOIN 不自动免费，设计时应尽量按分片键本地化。
093 分布式事务 2PC（两阶段提交）的不足是？
难度： 进阶
- A. 2PC 完全无阻塞，故障零影响
- B. 2PC 只能用于单机数据库
- C. 协调者单点、参与者阻塞、性能开销大，工程上常用最终一致性替代
- D. 2PC 会提高吞吐并减少网络开销
查看答案与解析
正确答案C
正确原因： 2PC 保证强一致，但协调者宕机会卡住参与者，通信轮次多、性能差。
关键边界： MySQL XA 可用于 2PC，但高并发场景下通常用最终一致性方案。
错误选项辨析： 2PC 有阻塞与单点问题，不限于单机，且开销大而非提高吞吐。
094 主从切换（failover）时最容易出现的风险是？
难度： 进阶
- A. 切换后从库自动拥有全部数据，零丢失
- B. 切换操作不会影响连接与路由
- C. 原主库未同步的 binlog 可能丢失，切换后数据不一致
- D. 主从切换无需任何人工确认
查看答案与解析
正确答案C
正确原因： 异步复制下原主在切换瞬间的未发送事务会丢失。
关键边界： 半同步、增强半同步或选最先进从库可降低丢失风险。
错误选项辨析： 零丢失不成立，切换会中断连接，需要确认与演练。
095 relay log 的作用是？
难度： 基础
- A. 主库暂存待发送给从库的日志
- B. 记录从库上用户的登录日志
- C. 替代 binlog 用于全量备份
- D. 从库暂存从主库拉取的 binlog 事件，供 SQL 线程回放
查看答案与解析
正确答案D
正确原因： relay log 位于从库本地，是复制两阶段的中转文件。
关键边界： relay log 格式与 binlog 一致，可通过 mysqlbinlog 查看。
错误选项辨析： 它不在主库、不是登录日志，也不替代 binlog。
096 MySQL 8.0 从库并行复制的作用是？
难度： 基础
- A. 从库只能用单线程回放
- B. 并行复制不需要 binlog
- C. 并行复制会让从库数据不一致
- D. 基于事务依赖关系多线程并行回放，缓解复制延迟
查看答案与解析
正确答案D
正确原因： 8.0 基于 WRITESET 或依赖分析实现多线程并行回放，前提通常是 row 格式 binlog。
关键边界： 并行度受事务依赖限制，大事务仍可能成为瓶颈。
错误选项辨析： 单线程是旧版限制，并行依赖 binlog，且能保证一致性。
097 业务读到从库旧数据（主从延迟）时的处理是？
难度： 实战
- A. 对强一致读路由到主库，弱一致场景可容忍或用版本号、时间戳校验
- B. 关闭从库读，全部走主库且不做任何拆分
- C. 无条件重试直到从库追上，可能无限等待
- D. 删除主从架构，改用单机数据库
查看答案与解析
正确答案A
正确原因： 延迟无法绝对消除，按一致性需求分级路由是常见做法。
关键边界： 关键操作后的即时读应强制走主库，弱一致读可接受短暂旧数据。
错误选项辨析： 全走主库失去读写分离价值，无限重试不可控，单机化不可扩展。
098 分片后需要跨分片全局排序分页（ORDER BY LIMIT）时？
难度： 实战
- A. 直接对每个分片取相同 offset，合并即正确
- B. 各分片先取局部 Top N，合并后在应用层再排序取前 N
- C. 全局排序分页完全免费，性能无损
- D. 分片后禁止任何 ORDER BY
查看答案与解析
正确答案B
正确原因： 各分片需取 offset 加 limit 条再归并排序，才能保证全局正确。
关键边界： 深分页成本高，是分布式分页的固有代价，可考虑游标分页。
错误选项辨析： 相同 offset 合并会漏数据，分页有成本，ORDER BY 仍可执行。
099 为什么需要同时存在 redo log 与 binlog？
难度： 基础
- A. 两份日志完全重复，只为磁盘冗余
- B. binlog 可以替代 redo 用于崩溃恢复
- C. redo 服务 InnoDB 崩溃恢复，binlog 服务复制与时间点恢复，二者职责不同
- D. redo 可以替代 binlog 用于主从复制
查看答案与解析
正确答案C
正确原因： 崩溃恢复需要物理页重做（redo），复制与时间点恢复需要逻辑变更（binlog）。
关键边界： 两阶段提交保证两份日志在事务边界上一致。
错误选项辨析： 两者职责不同不可替代，互为补充而非冗余。
100 复制中遇到临时表、自增等行为时，statement 格式的风险是？
难度： 进阶
- A. statement 格式总是比 row 格式更安全
- B. 复制只支持 statement 一种格式
- C. 临时表与自增对复制没有任何影响
- D. 不同实例执行结果可能不同，导致主从不一致，row 格式更安全
查看答案与解析
正确答案D
正确原因： 非确定性语句（无排序 LIMIT、临时表、UUID、自增依赖）在 statement 下可能产生不同结果。
关键边界： row 格式记录行级变更结果，一致性最好，8.0 默认采用。
错误选项辨析： row 更安全，复制支持多种格式，临时表与自增正是典型风险点。