主从架构凭借一主多从的部署方式，在读取密集型系统中被广泛使用。主节点承担所有写请求并向从节点同步变更，从节点对外提供读服务。但当业务写入量持续上涨，或读流量需要跨分片聚合时，这种架构的扩展边界就会显现。评估读写扩展能力，核心在于区分“读扩展”与“写扩展”两条路径，并判断分库分表与中间件方案分别适合哪种瓶颈。
一、主从架构的扩展边界在哪里
读扩展相对容易，只要增加从节点并挂载到主库，就能把查询压力分摊出去。但需要注意，从节点数量并非越多越好：每个从节点都要与主库建立 binlog 复制通道，主库在事务提交时需等待或推送日志，从节点过多会放大主库的网络与磁盘开销。一般经验下，单主配合三到五个从节点是比较稳妥的区间，超过后主库自身反而可能成为瓶颈。
写扩展则困难得多。主从架构中写操作只能落在唯一的主节点，无论后面挂多少从库，写入吞吐都受限于主库的单机 CPU、内存与磁盘 IOPS。当每日写入行数达到千万级，或单表体积突破千万行引发索引膨胀时，仅靠主从复制已经无法解决问题，必须引入数据拆分思路。
二、分库分表如何突破单点写瓶颈
分库分表是把原本集中的数据，按某个分片键（如用户 ID、订单 ID）分散到多个数据库实例或表中。常见的有垂直分库（按业务模块拆）和水平分表（按行范围或哈希拆）。水平拆分直接降低了单库单表的数据量，使写入能并行落到不同主库，从而线性提升写能力。
下面是一段基于用户 ID 取模分库的简单路由示例：
// 根据 userId 计算落在哪个数据库分片，共 4 个分库
public String getDataSourceKey(long userId) {
int shardCount = 4;
// 取绝对值后取模，避免负数
int index = (int)(Math.abs(userId) % shardCount);
return "ds_" + index;
}
// 插入订单时选择对应分片
public void insertOrder(long userId, Order order) {
String dsKey = getDataSourceKey(userId);
// 假设通过 Spring 的 AbstractRoutingDataSource 切换
DataSourceContextHolder.set(dsKey);
orderMapper.insert(order);
}
分库分表的优势是性能收益直接，没有中间层转发损耗。但缺点也同样明显：跨分片查询（如按非分片键统计）需要聚合多个库结果；分布式事务要保证多库一致性，通常得引入柔性事务或最终一致方案；运维上备份、扩容、数据迁移都更加复杂。因此在评估时，应重点测算分片键的离散度与核心查询的命中率。
分库分表适用场景清单
- 单表数据量超过千万且持续快速增长
- 写请求明显集中于单一业务实体（如订单、流水）
- 团队有能力维护多数据源与分布式事务框架
三、MyCat 与 Sharding 中间件的价值与代价
MyCat 是一类以代理方式存在的中间件，应用像连接普通 MySQL 一样连接 MyCat，由它解析 SQL 并路由到后端真实分库。ShardingSphere（常称 Sharding 中间件）则以 JDBC 增强或 Sidecar 形态嵌入，逻辑分片对代码相对透明。二者都试图把分库分表的复杂度从业务层下沉到基础设施层。
使用 ShardingSphere 的 YAML 配置片段如下：
# 配置两个真实数据源
dataSources:
ds0:
url: jdbc:mysql://192.168.0.1:3306/db0
username: root
password: pass
ds1:
url: jdbc:mysql://192.168.0.2:3306/db1
username: root
password: pass
# 按 order_id 哈希分片到 ds0 和 ds1
shardingRule:
tables:
t_order:
actualDataNodes: ds$->{0..1}.t_order
databaseStrategy:
inline:
shardingColumn: order_id
algorithmExpression: ds$->{order_id % 2}
中间件的优点是对业务侵入小，研发不必在每个方法里手写路由逻辑；并且统一处理了跨分片结果归并。代价是增加了一层网络或进程内解析，SQL 支持度可能受限（如某些存储过程、特殊函数无法下推），同时排查慢查询时要区分是中间件还是后端库的问题。评估读写扩展能力时，必须把这些额外延迟计入总体 RT。
MyCat 与 Sharding 对比要点
| 维度 | MyCat | ShardingSphere |
|---|---|---|
| 部署形态 | 独立代理进程 | JDBC 层或 Sidecar |
| 性能损耗 | 网络转发明显 | 进程内较低 |
| 运维复杂度 | 需独立运维代理 | 随应用发布 |
四、综合评估读写扩展能力的步骤
第一步，梳理当前主从延迟与主库负载曲线，确认瓶颈是读还是写。若从库延迟高但主库空闲，说明读扩展不足，加从节点或引入缓存即可。若主库 CPU 常满，则必须考虑写拆分。
第二步，统计核心表的写入增速与单表大小，预估半年后是否触达分表阈值。第三步，列出高频查询条件，检验分片键能否覆盖多数请求；若大量查询走非分片键，中间件虽能路由但归并成本高，分库分表收益会打折。最后结合团队运维水平，选择自研分片、MyCat 还是 Sharding 类方案，并用压测验证扩展拐点。
只有把业务模型、数据分布与中间件开销放在一起量化，才能准确回答主从架构到底还能不能继续扩、该怎么扩。
主从架构分库分表MyCat_Sharding修改时间：2026-08-05 21:12:35