Java八股文——MySQL「架构篇」

MySQL主从复制了解吗

面试官您好，我了解MySQL的主从复制。它是构建高可用、高可扩展数据库架构的核心基石。

1. 主从复制的核心原理与流程

整个主从复制的过程，就是一场围绕 binlog（二进制日志） 的“接力赛”。这个过程主要可以分为三个大的阶段：

阶段一：主库记录变更 (Master Writes Binlog)
- 当主库（Master）执行一个写操作（INSERT, UPDATE, DELETE）并提交事务时，它会按照两阶段提交的协议，将这次数据变更的逻辑操作记录到自己的binlog文件中。
阶段二：从库同步日志 (Slave Fetches Binlog)
- 从库（Slave）上有一个专门的I/O线程。它的唯一任务就是与主库建立一个长连接，并请求主库的binlog。
- 主库上有一个对应的 log dump线程，它在接收到从库的请求后，会源源不断地把新的binlog内容推送给从库的I/O线程。
- 从库的I/O线程在接收到binlog数据后，并不是直接执行，而是先将其原封不动地写入到本地的一个叫做“中继日志”（relay log）的文件中。
- 为什么需要relay log？ 这是一种解耦设计。它将“网络数据接收”和“本地数据重放”这两个步骤分离开。即使后续的重放操作比较慢，也不会影响I/O线程从主库拉取数据的速度，提高了主从同步的稳定性和效率。
阶段三：从库重放日志 (Slave Replays Relay Log)
- 从库上还有另一个专门的SQL线程（在MySQL 5.6之后可以是多线程的）。
- 它的任务就是不断地读取relay log，解析出其中的SQL语句或行变更事件，然后在从库上原样地、按顺序地执行一遍，从而使得从库的数据与主库保持最终一致。

2. 主从复制的模式

默认情况下，主从复制是异步的。

异步复制 (Asynchronous)
- 主库在执行完一个事务、写完binlog后，不会等待从库的任何响应，会立即返回成功给客户端。
- 优点：性能最高，对主库的性能影响最小。
- 缺点：数据可能不一致。如果主库在binlog发送给从库之前就宕机了，那么这个事务的数据就会在从库上永久丢失，导致主从数据不一致。
半同步复制 (Semi-synchronous)
- 为了解决异步复制的数据丢失问题，MySQL引入了半同步复制。
- 工作模式：主库在提交事务后，会阻塞等待，直到至少有一个从库接收到binlog并写入自己的relay log后，主库才会返回成功给客户端。
- 优点：在很大程度上保证了数据的高可用性。只要不是主从在同一时间点上一起宕机，数据就不会丢失。
- 缺点：增加了主库的响应延迟，对性能有一定影响。

3. 主从复制的核心应用价值

读写分离：这是最常见的应用。我们可以让主库专门负责写操作，而将大量的读请求，分散到多个从库上。这极大地分担了主库的压力，提升了整个数据库集群的查询吞吐量。
高可用与灾备：当主库发生故障时，我们可以快速地将一个从库提升为新的主库，从而实现服务的快速恢复，保证了业务的连续性。
数据备份：我们可以在从库上进行数据备份，而完全不影响主库的正常服务。

4. 面临的挑战

主从延迟 (Replication Lag)：这是主从复制中最核心的挑战。由于网络延迟、从库SQL线程执行慢等原因，从库的数据可能会落后于主库。我们需要对主从延迟进行持续的监控和告警，并通过优化SQL、提升从库硬件、开启并行复制等手段来缓解这个问题。

总结一下，MySQL主从复制通过一套精巧的、基于binlog的日志同步与重放机制，为我们构建可扩展、高可用的数据库架构提供了强大的基础。

主从延迟都有什么处理方法？

面试官您好，主从延迟是MySQL主从架构中一个非常常见、也必须重点关注的问题。解决它，需要一个 “监控、分析、优化、容忍” 相结合的系统性方案。

第一步：监控与发现 —— “让延迟无所遁形”

在讨论如何解决之前，我们首先得能准确地监控到延迟。我会通过SHOW SLAVE STATUS;命令，重点关注以下两个指标：

Seconds_Behind_Master: 这是最直观的指标，它表示从库SQL线程执行的时间点，落后于主库I/O线程接收到binlog的时间点有多少秒。我会对这个值设置一个合理的阈值（比如超过5秒）进行持续的监控和告警。

第二步：原因分析 —— “延迟到底发生在哪里？”

主从延迟的根本原因，是从库消费binlog的速度，跟不上主库生成binlog的速度。这可能发生在两个环节：

网络延迟：主库和从库之间的网络状况不佳，导致I/O线程拉取binlog就比较慢。
从库执行慢（最常见的原因）：
- 从库硬件配置差：从库的磁盘I/O能力或CPU性能，远低于主库。
- 从库是“单线程作战”：在MySQL 5.6之前，从库的SQL线程是单线程的。如果主库上是多个线程在并行写入，而从库却只能串行回放，延迟就很容易产生。
- 主库上存在“大事务”或慢SQL：一个在主库上执行了10分钟的大事务，或者一条没有索引的慢查询，当它传到从库时，同样会阻塞SQL线程10分钟，造成巨大的延迟。
- 从库上有其他查询压力：如果从库除了要回放binlog，还承担了大量的实时报表、数据分析等慢查询任务，也会拖慢SQL线程的执行。

第三步：解决方案 —— “多管齐下”

针对以上原因，我会采用一整套组合拳来解决主从延迟。

1. 硬件与网络优化（基础保障）
- 保证从库的硬件配置不低于主库，特别是磁盘I/O性能。
- 优化主从之间的网络连接，比如使用专线、万兆网卡等。
2. 开启并行复制（核心优化）
- 这是解决从库执行慢的最核心、最有效的手段。
- MySQL 5.6：引入了基于库（DATABASE） 的并行复制，即不同数据库的更新可以并行回放。
- MySQL 5.7：引入了更强大的基于逻辑时钟（LOGICAL_CLOCK） 的并行复制。它能做到在同一个库内，只要是没有数据冲突的事务，都可以并行回放，大大提升了复制效率。
- MySQL 8.0：进一步增强，引入了基于写集合（WRITESET） 的并行复制，能更精准地判断事务是否可以并行。
- 在生产环境中，开启并合理配置并行复制是必须的操作。
3. 优化主库的SQL（源头治理）
- 避免大事务：在应用层，将大的DML操作，拆分成多个小事务分批执行。
- 杜绝慢查询：所有在主库上执行的SQL都必须经过EXPLAIN审核，确保都用上了合适的索引，避免全表扫描。
4. 架构层面的业务容忍方案

当上述优化都做了，但仍然可能存在无法完全消除的、秒级的延迟时，我们就需要从业务层面来设计一些容忍方案。

a. 读写分离的“半同步”读取
- 场景：对于一些对实时性要求极高的读请求，比如用户刚支付完，立刻查询订单状态。
- 方案：可以让这个特定的读请求，在执行SELECT之前，先执行一条SELECT MASTER_POS_WAIT(file, pos, timeout)命令。这个命令会阻塞当前会话，直到从库的SQL线程追赶到指定的binlog位置（这个位置可以从写操作成功后获取），或者超时。这样就能保证这次读取，一定能读到最新的数据。
b. 强制走主库（最后的兜底方案）
- 这是最直接但代价也最大的方案。
- 做法：在应用代码中，通过路由机制（比如使用特定的数据源注解），将那些绝对不能接受任何延迟的读请求（比如金融交易的余额查询），强制路由到主库去执行。
- 权衡：这个方案能100%保证数据实时性，但会增加主库的读压力，需要谨慎使用，只用于最关键的业务路径。

总结一下，解决主从延迟，我会先通过并行复制和源头SQL优化来尽可能地缩短延迟。对于仍然存在的、不可避免的微小延迟，再通过业务层面的“半同步读”或“强制走主库” 等方案，来满足不同场景对数据实时性的要求。

分表和分库是什么？有什么区别？

面试官您好，分库和分表是当单一数据库或单张数据表的性能或容量达到瓶颈时，我们为了提升系统的可扩展性（Scalability） 而采用的一种核心的数据库架构演进策略。

它们解决问题的维度不同，可以看作是两种不同方向的“拆分”：

1. 分表 (Sharding / Partitioning) —— “内部装修，缓解单表压力”

它是什么？
- 分表指的是，将一张数据量巨大的单表，按照某个规则，拆分成多张结构完全相同的小表。这些小表通常还在同一个数据库实例中。
分表主要有两种拆分方式：
- a. 垂直分表 (Vertical Partitioning)
  - 思路：“按列拆”。把一张字段非常多的“宽表”，拆分成多张“窄表”。
  - 原则：通常是把常用的、访问频繁的字段放在一张主表中，而把不常用的、或者字段本身很大（如TEXT, BLOB）的字段，拆分到另一张扩展表中。两张表通过同一个主键关联。
  - 解决了什么问题？
    - 提升I/O效率：核心表的单行数据变小，一个数据页能容纳更多行，查询核心数据时I/O次数减少。
    - 缓存效率更高：Buffer Pool可以用有限的内存，缓存更多核心表的数据行。
- b. 水平分表 (Horizontal Partitioning)
  - 思路：这是我们通常意义上说的“分表”，即“按行拆”。把一张行数巨大（比如上亿条）的表，按照某个规则，分散到多张物理表中。
  - 规则：常见的有按范围（Range） 分片（如按月份、按ID区间）或按哈希（Hash） 分片（如按用户ID取模）。
  - 解决了什么问题？
    - 缓解单表数据量瓶颈：单表数据量过大，会导致B+树索引层高增加，查询和写入性能都会急剧下降。分表后，每张小表的索引树都变得很小、很浅，性能得到极大提升。
    - 锁竞争降低：对于高并发的写操作，请求被分散到不同的物理表中，锁的竞争也随之减少。

2. 分库 (Database Sharding) —— “另起炉灶，分散整体压力”

它是什么？
- 分库指的是，将一个数据库实例，按照业务或功能，拆分成多个独立的数据库实例。这些实例可以部署在不同的物理服务器上。
分库也有两种拆分方式：
- a. 垂直分库
  - 思路：“按业务拆”。将一个庞大的、耦合的数据库，按照业务边界，拆分成多个独立的微服务数据库。
  - 例子：一个电商系统，可以拆分成“用户库”、“商品库”、“订单库”、“支付库”等。
  - 解决了什么问题？
    - 业务解耦与隔离：不同业务线使用独立的数据库，互不影响。一个业务的数据库出现问题，不会波及到其他业务。
    - 突破单机资源瓶颈：将压力分散到多台服务器上，解决了单台服务器的CPU、内存、I/O、网络带宽的瓶颈。
- b. 水平分库
  - 思路：当单个业务的数据库（比如“订单库”）本身也遇到了性能瓶颈时，就需要对这个库进行水平拆分。
  - 做法：将原先一个库里的表，按照水平分表的方式，分散到多个数据库实例中。比如，订单表orders_0到orders_255，可能0-127的表在DB1，128-255的表在DB2。

3. 区别与联系

对比维度	分表 (Table Sharding)	分库 (Database Sharding)
拆分对象	单张大表	整个数据库实例
物理位置	通常在同一个数据库实例内	分散在多个数据库实例/服务器上
解决问题	单表的查询/写入性能瓶颈	整个数据库的并发压力和数据容量瓶颈
实现复杂度	相对简单	复杂，引入了分布式事务等问题
常见组合	通常与分库结合使用	是更大范围的拆分策略