读写分离与全量主库两种模式，核心区别在于“读流量”如何处理：读写分离适合读多写少、对扩展性有要求的业务，全量主库适合数据量小、一致性要求极高的场景。选错模式，轻则浪费机器，重则引发数据不一致事故，下面直接从负载特征、典型场景、架构代价三个维度拆解，帮你对号入座。
读写分离适合什么场景：读多写少且能容忍秒级延迟
读写分离的本质,是把主库的写压力与从库的读压力物理隔离，它解决的不是性能天花板，而是并发读的横向扩展问题。
典型负载画像：读占比超过80%的互联网业务
判断业务是否适合读写分离,先看两个硬指标：
- 读写比例：读请求占总请求量80%以上时，从库才能分摊实质压力，如果读写五五开，从库扩容带来的收益会被主从同步开销抵消。
- 写峰值的容忍度：主库写入后，从库存在复制延迟，业务能否接受“刚写入的数据在几百毫秒内读不到”？
行业共识认为,延迟敏感度是比读写比更优先的判断标准，比如订单支付成功页跳转，用户刚付款就看不到订单状态，体验是灾难性的，而商品详情页、资讯列表这类场景，延迟几百毫秒几乎无感。
适合读写分离的三种具体业务形态
型平台：文章、视频、商品信息天然是“一次写入，多次读取”，例如电商的商品详情页，SKU数据写入后长期不变，读流量却是写流量的几十倍。
- 后台报表统计：业务库承担OLTP写入，统计查询通过从库跑复杂聚合，互相不干扰，常见做法是把从库作为BI报表的数据源。
- 跨地域读加速：主库部署在华东，华南用户读延迟高，通过在不同地域部署只读从库，就近读取，这是读写分离的延伸用法。
读写分离不适合哪些负载
- 秒杀、抢购类：写流量瞬间暴涨，从库根本帮不上忙，此时需要的是分库分表或队列削峰。
- 强一致金融交易：账户余额、库存扣减，崩溃恢复后主从不一致是致命的，这类系统即使读多写少，也应优先考虑全量主库。
- 数据量超千万级的单表：读写分离不解决单表数据量过大的问题，当单表超过千万行，即使读压力拆到10个从库，每个从库的查询同样慢。
全量主库模式优缺点：简单可靠但扩展上限清晰
全量主库,就是所有读写请求都打到单一数据库实例，别急着否定它，在特定负载下，这是
成本最低、一致性最强的方案。
全量主库模式优点：没有复制延迟，没有数据分片悖论
- 强一致性天然满足：读写都在同一实例，事务隔离级别下的所有操作立即可见，不需要补偿机制。
- 架构极简：没有主从同步、没有故障切换、没有读路由逻辑，一个连接串搞定所有配置。
- 运维成本低：不需要监控从库延迟、不需要处理复制中断修复，DBA人力投入减少一大半。
- 写性能无放大效应：主从架构中，主库写一次，从库同步写一次，磁盘IO翻倍，全量主库写路径最短。
全量主库模式缺点：单点故障与性能天花板
- CPU/内存扩展受限：单机规格上限决定并发能力，即使换成128核高端机器，连接数、锁竞争也会先到瓶颈。
- 读流量挤占写资源：大查询会阻塞小写入，一个慢SQL就能拖垮整个业务。
- 故障影响半径大：主库宕机，业务直接停摆，不像从库可以只读降级。
读写分离和主库模式怎么选：负载分层决策法
不要抽象讨论优劣,直接看业务负载的三个维度：读并发数、写TPS、数据一致性容忍度。
决策步骤：先量化，再选型
- 用监控工具采集峰值时段的数据,确认读QPS、写TPS、慢查询数量三板斧。
- 计算读QPS与写TPS的比例。比例超过10:1且未来半年读流量有增长趋势，优先考虑读写分离。
- 检查业务代码中是否存在“写入后立即读取”的关键路径，若有，评估能否通过缓存消除延迟影响。
- 统计单表数据量,超过500万行，优先考虑归档或分表，而不是无脑上从库。
小项目预算有限，全量主库是不是够用
很多创业团队问：全量主库适合小项目吗？答案是：初期完全够用，一个日活1万的业务，读QPS一般不到500，单台4核8G的云数据库（比如简米云RDS基础版）就能扛住，价格每月两三百元，如果此时强行搭读写分离，至少需要主从两台实例，成本翻倍，还要处理主从延迟带来的隐性bug。
业内专家指出，低于5000读QPS的业务，全量主库配合Redis缓存是最优解，性能轻松支撑，架构复杂度最低，盲目追求读写分离反而是过度设计。
读写分离部署方案：从半同步到多从库集群
当确定需要读写分离,部署遵循渐进式路径：
第一阶段：一主一从，半同步复制
- 主库开启
rpl_semi_sync_master_enabled=1，从库开启rpl_semi_sync_slave_enabled=1，半同步保证主库提交后至少一个从库收到binlog，丢数据窗口缩小到极致。 - 应用层通过
@Transactional(readOnly = true)或MyBatis插件把查询路由到从库。
第二阶段：一主多从，按场景拆分
- 三个从库分别承担：常规查询、报表分析、备份恢复，避免OLAP查询拖垮OLTP读。
- 引入中间件如ProxySQL或ShardingSphere,用SQL正则规则自动路由。
第三阶段：读写分离与分库分表结合
- 当单库写TPS超过2000,或单表数据量超过千万，读写分离无法解决根本问题，此时按业务ID哈希分片，每个分片内再搭主从。
数据一致性成本：从库延迟的三种补救策略
读写分离绕不开延迟问题,以下方案按成本从低到高排列：
- 关键路径强制走主库：订单详情页，通过请求头标识或用户ID哈希，让刚下订单的用户查主库，其他用户查从库。
- 缓存穿透保护：延迟最常发生在“更新后读旧数据”，写操作后删除对应Redis缓存，读请求缓存未命中时先从主库拉取并回填。
- GTID感知路由：从库通过
gtid_executed返回当前位置，应用层记录写入事务的GTID，查询从库时校验GTID是否已同步，未同步则挂起等待或降级主库。
读写分离性能提升多少：真实数据参考
不掰扯理论,看实际压测结果，在标准电商读取场景（2000并发，64核数据库实例）下：
- 全量主库读QPS峰值约2万，CPU使用率已到80%。
- 增加一个只读从库后,总读QPS约3万，提升接近一倍，但主库CPU降到35%。
- 增加3个从库后,读QPS可突破5万，但边际收益递减每个从库的提升从100%降到50%左右。
读写分离的性能提升与从库数量成正比,但受限于主库同步线程和网络带宽，建议从库数量不超过5个，除非用异步复制。
数据库负载均衡的最终形态：两种模式混合使用
很多业务并非非黑即白,一个中型电商系统，商品库用读写分离应对高并发浏览，订单库用全量主库保证事务强一致，更好的方案是按业务模块拆分：
- 商品、评价、搜索等读多写少模块 → 读写分离，每个模块独立从库。
- 订单、支付、库存扣减模块 → 全量主库，确保绝对一致。
- 数据分析模块 → 单独从库，甚至从库只读副本再搭建数据仓库。
这种混合部署也叫“读写分离分片混合架构”，比单纯选一种模式更能匹配复杂负载。
混合部署的切换红线
- 订单表迁移到读写分离前,必须改造事务边界，禁止跨多个从库的联合查询。
- 从库数据延迟超过阈值（比如5秒），自动熔断切回主库，可通过监控
Seconds_Behind_Master实现告警。
Q&A：读写分离和全量主库选择常见问题
问：读写分离架构会提高多少成本？
成本主要分为三块：实例费用、网络带宽、运维人力，一台基础版从库的价格是主库的50%到70%（云厂商折扣后），如果主库是4核8G（约600元/月），增加一个从库大约每月多支出400元，但需要额外购买内网流量包，从库同步binlog会产生流量费用，总体算下来，一主一从成本增加60%左右。
问：全量主库模式如何应对突发流量？
全量主库的应对手段是临时升级规格和限流降级，突发流量到来，先在云控制台将CPU从4核临时升到16核，完成后再降回来，按小时计费，在应用层对非核心接口（比如历史订单查询）做限流，保住核心写入路径，如果突发流量是常态，再考虑迁移到读写分离。
问：读写分离和分库分表有什么区别？
读写分离处理的是“同一份数据的并发读”，所有从库数据完全一致，解决横向读扩展，分库分表处理的是“数据量过大导致的单机存储和写入瓶颈”，是把数据切分成多份，每个分片有独立主从架构，实践中，先分表，再在分片内搭主从，两种技术结合使用，单纯读写分离无法应对单表千万级数据。
最后再强调一次选型没有最好，只有匹配负载，读写分离解决读流量洪水，全量主库守住写一致性大坝。先看读请求占比，再看延迟容忍度，最后算成本账，答案自然清晰。 当业务数据量还在百万级，别纠结，全量主库加缓存就是最优解。