当单库压力越来越大时常见演进路线是先做主从复制再做读写分离如果数据量和写入压力继续增长就需要考虑分库分表。这三者解决的问题不同方案主要解决什么主从复制数据冗余、读扩展、故障切换基础读写分离缓解读请求对主库的压力分库分表解决单库、单表数据量和并发瓶颈主从复制的核心binlogMySQL 主从复制的核心是二进制日志也就是 binlog。binlog 记录 DDL 和 DML 语句但不记录普通查询语句。复制过程可以拆成三步主库事务提交时把数据变更写入 binlog。从库读取主库 binlog并写入自己的 relay log。从库重放 relay log 中的事件把变更应用到自己的数据中。流程图更直观主库提交事务写入 binlog从库 IO 线程拉取 binlog写入 relay log从库 SQL 线程重放事件从库数据追上主库这里有三个关键词组件作用Master主库负责写入并产生 binlogBinlog主库记录数据变更的日志Relay Log从库拉取 binlog 后保存的中继日志读写分离解决什么如果业务读多写少写操作可能影响查询效率。读写分离的思路是写请求走主库读请求走从库。典型路径是应用或数据库代理识别 SQL 类型。insert、update、delete发到主库。select发到从库。主库通过复制把变更同步给从库。写操作读操作应用发起 SQLSQL 类型路由到主库路由到从库主库写 binlog复制到从库返回查询结果读写分离能分担访问压力但也带来一个常见问题主从延迟。刚写入的数据立刻去从库查可能暂时查不到。解决方式包括强制读主库、延迟敏感业务不走从库、根据复制延迟动态路由等。什么时候考虑分库分表分库分表不是一开始就要做。它会显著增加系统复杂度应该在常规优化已经不足时再考虑。常见信号包括业务数据持续增长单表已经非常大。索引、SQL、缓存、读写分离等优化后仍无法满足性能。出现磁盘 IO、网络 IO、CPU 或连接数瓶颈。单表数据量达到千万级或者单表文件非常大。分库分表解决的是更底层的问题单库容量、单表性能、写入并发、IO 争抢。是否要走到分库分表可以先用这张决策图压一压复杂度否是是否是否是否是否数据库性能或容量出现瓶颈SQL 和索引是否已优化先优化 SQL、索引、表结构是否读多写少优先主从复制和读写分离是否单表数据量过大考虑水平分表是否单库连接数或 IO 成为瓶颈考虑水平分库或垂直分库继续观察业务增长和热点数据读写分离后是否仍有瓶颈暂不引入分库分表垂直拆分垂直拆分是按业务或字段拆。垂直分库垂直分库以表为依据根据业务边界把不同表拆到不同库。例如库表用户库用户、账号、权限订单库订单、支付、售后商品库商品、库存、类目它的好处是按业务独立管理、维护和扩展也能减少单库连接数和 IO 压力。垂直分表垂直分表以字段为依据把一个表中的字段拆到不同表。常见规则把不常用字段拆出去。把text、blob等大字段拆到附表。做冷热数据分离减少主表 IO。例如用户主表只保留高频字段用户详情表保存头像、简介、扩展配置等低频字段。水平拆分水平拆分是按数据行拆。表结构通常相同只是数据被分散到多个库或多张表。水平分库水平分库是把同一类数据拆到多个库中。例如按用户 ID 取模user_id % 3 0 - db_0 user_id % 3 1 - db_1 user_id % 3 2 - db_2它能解决单库数据量和高并发瓶颈提高系统稳定性和可用性。水平分表水平分表是把同一张表的数据拆到多张表中可以在同一个库内也可以跨库。例如order_0000 order_0001 order_0002 ...它主要解决单表过大导致的查询、写入、索引维护和锁竞争问题。分库分表带来的新问题拆分后性能瓶颈缓解了但复杂度会上来。问题说明分布式事务一次业务操作可能跨多个库跨节点关联查询join 不再像单库中那么自然跨节点分页排序需要汇总多节点结果再排序全局主键多节点生成 ID 需要避免冲突路由规则应用要知道数据在哪个库、哪张表常见中间件包括 ShardingSphere 和 MyCat。它们可以帮助处理路由、分片、读写分离等问题但不能消除架构复杂度。面试回答模板可以这样回答MySQL 主从复制依赖 binlog。主库提交事务时写 binlog从库读取 binlog 写入 relay log再重放 relay log 完成数据同步。读写分离是在主从复制基础上把写请求发到主库读请求发到从库用来缓解读压力但要注意主从延迟。当单库单表数据量或并发继续增长普通优化已经解决不了 IO、CPU、连接数和单表性能问题时可以考虑分库分表。分库分表分为垂直分库、垂直分表、水平分库、水平分表但会带来分布式事务、跨节点查询、分页排序和主键避重等新问题。小结主从复制、读写分离和分库分表是一条逐步升级的路线。主从复制解决数据同步和读扩展基础读写分离缓解读压力分库分表处理更大的容量和并发问题。越往后收益越大复杂度也越高设计时一定要先确认瓶颈是否真的到了这一步。
MySQL高可用与扩展-主从复制读写分离分库分表
发布时间：2026/5/17 3:36:50
当单库压力越来越大时常见演进路线是先做主从复制再做读写分离如果数据量和写入压力继续增长就需要考虑分库分表。这三者解决的问题不同方案主要解决什么主从复制数据冗余、读扩展、故障切换基础读写分离缓解读请求对主库的压力分库分表解决单库、单表数据量和并发瓶颈主从复制的核心binlogMySQL 主从复制的核心是二进制日志也就是 binlog。binlog 记录 DDL 和 DML 语句但不记录普通查询语句。复制过程可以拆成三步主库事务提交时把数据变更写入 binlog。从库读取主库 binlog并写入自己的 relay log。从库重放 relay log 中的事件把变更应用到自己的数据中。流程图更直观主库提交事务写入 binlog从库 IO 线程拉取 binlog写入 relay log从库 SQL 线程重放事件从库数据追上主库这里有三个关键词组件作用Master主库负责写入并产生 binlogBinlog主库记录数据变更的日志Relay Log从库拉取 binlog 后保存的中继日志读写分离解决什么如果业务读多写少写操作可能影响查询效率。读写分离的思路是写请求走主库读请求走从库。典型路径是应用或数据库代理识别 SQL 类型。insert、update、delete发到主库。select发到从库。主库通过复制把变更同步给从库。写操作读操作应用发起 SQLSQL 类型路由到主库路由到从库主库写 binlog复制到从库返回查询结果读写分离能分担访问压力但也带来一个常见问题主从延迟。刚写入的数据立刻去从库查可能暂时查不到。解决方式包括强制读主库、延迟敏感业务不走从库、根据复制延迟动态路由等。什么时候考虑分库分表分库分表不是一开始就要做。它会显著增加系统复杂度应该在常规优化已经不足时再考虑。常见信号包括业务数据持续增长单表已经非常大。索引、SQL、缓存、读写分离等优化后仍无法满足性能。出现磁盘 IO、网络 IO、CPU 或连接数瓶颈。单表数据量达到千万级或者单表文件非常大。分库分表解决的是更底层的问题单库容量、单表性能、写入并发、IO 争抢。是否要走到分库分表可以先用这张决策图压一压复杂度否是是否是否是否是否数据库性能或容量出现瓶颈SQL 和索引是否已优化先优化 SQL、索引、表结构是否读多写少优先主从复制和读写分离是否单表数据量过大考虑水平分表是否单库连接数或 IO 成为瓶颈考虑水平分库或垂直分库继续观察业务增长和热点数据读写分离后是否仍有瓶颈暂不引入分库分表垂直拆分垂直拆分是按业务或字段拆。垂直分库垂直分库以表为依据根据业务边界把不同表拆到不同库。例如库表用户库用户、账号、权限订单库订单、支付、售后商品库商品、库存、类目它的好处是按业务独立管理、维护和扩展也能减少单库连接数和 IO 压力。垂直分表垂直分表以字段为依据把一个表中的字段拆到不同表。常见规则把不常用字段拆出去。把text、blob等大字段拆到附表。做冷热数据分离减少主表 IO。例如用户主表只保留高频字段用户详情表保存头像、简介、扩展配置等低频字段。水平拆分水平拆分是按数据行拆。表结构通常相同只是数据被分散到多个库或多张表。水平分库水平分库是把同一类数据拆到多个库中。例如按用户 ID 取模user_id % 3 0 - db_0 user_id % 3 1 - db_1 user_id % 3 2 - db_2它能解决单库数据量和高并发瓶颈提高系统稳定性和可用性。水平分表水平分表是把同一张表的数据拆到多张表中可以在同一个库内也可以跨库。例如order_0000 order_0001 order_0002 ...它主要解决单表过大导致的查询、写入、索引维护和锁竞争问题。分库分表带来的新问题拆分后性能瓶颈缓解了但复杂度会上来。问题说明分布式事务一次业务操作可能跨多个库跨节点关联查询join 不再像单库中那么自然跨节点分页排序需要汇总多节点结果再排序全局主键多节点生成 ID 需要避免冲突路由规则应用要知道数据在哪个库、哪张表常见中间件包括 ShardingSphere 和 MyCat。它们可以帮助处理路由、分片、读写分离等问题但不能消除架构复杂度。面试回答模板可以这样回答MySQL 主从复制依赖 binlog。主库提交事务时写 binlog从库读取 binlog 写入 relay log再重放 relay log 完成数据同步。读写分离是在主从复制基础上把写请求发到主库读请求发到从库用来缓解读压力但要注意主从延迟。当单库单表数据量或并发继续增长普通优化已经解决不了 IO、CPU、连接数和单表性能问题时可以考虑分库分表。分库分表分为垂直分库、垂直分表、水平分库、水平分表但会带来分布式事务、跨节点查询、分页排序和主键避重等新问题。小结主从复制、读写分离和分库分表是一条逐步升级的路线。主从复制解决数据同步和读扩展基础读写分离缓解读压力分库分表处理更大的容量和并发问题。越往后收益越大复杂度也越高设计时一定要先确认瓶颈是否真的到了这一步。
