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. 主从复制的核心应用价值

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

4. 面临的挑战

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

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

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

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

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

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

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

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

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

1. 网络延迟：主库和从库之间的网络状况不佳，导致I/O线程拉取binlog就比较慢。
2. 从库执行慢（最常见的原因）：
   • 从库硬件配置差：从库的磁盘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. 区别与联系

总结一下：

• 分表是“治标”，主要解决的是单张表因为数据量过大而导致的性能问题，它是在一个数据库实例内部的优化。
• 分库是“治本”，主要解决的是整个数据库实例因为并发压力过大或数据容量过大而遇到的瓶可瓶颈，它将压力分散到多个物理服务器上。

在实际的系统演进中，往往是先进行垂直分库（按业务拆分），然后在某个业务高速发展、数据量激增时，再对这个业务的库进行水平分库和分表。这是一个循序渐进的架构演进过程。