大促前只读副本该什么时候扩容？核心答案只有一句：在全链路压测通过之后、大促开始前的3到7天内把规格和数量一次配到位，再留出至少48小时观察复制延迟和缓存预热，别等到流量洪峰前一夜才动手。
只读副本不是万能插座,插上就能分流，它像给高峰期的收银台临时加开窗口，加得早了浪费人力，加得晚了队伍已经排到门外，下面按“判断瓶颈、对比方案、落地操作、算清成本、盯住地域差异”的顺序，把扩容时机这件事拆开讲。
大促前数据库只读副本什么时候扩容合适
这个问题没有统一日历答案,但有统一的判断逻辑：扩容时机由“压测结论”倒推，不由大促日期正推。
先确认瓶颈真的落在只读副本身上
很多团队一到大促就条件反射扩容,结果钱花了、问题没解决，动手前先看三组指标：
- 主库的CPU水位、活跃连接数、慢查询数量，主库自己就快撑不住了，加只读副本只会让复制压力更大。
- 只读副本的读QPS、CPU、内存命中率，读副本CPU长期贴着高位跑，才是真瓶颈。
- 复制延迟曲线,延迟在业务高峰时段出现尖峰，说明副本的apply线程跟不上主库写入。
如果读请求占比很高、写请求相对平稳，只读副本扩容的收益最直接；反过来，写多读少，扩副本基本是隔靴搔痒。
扩容的三个提前量，一个都不能省
行业共识认为,只读副本扩容真正的风险不在扩本身，而在扩完之后没有时间验证，所以时间窗口要倒着排：
- 压测提前量：全链路压测跑完，把目标流量压到预估峰值的1.2到1.5倍，确认扩容后的副本能扛住，压测没通过就扩容，等于闭着眼睛下单。
- 复制延迟观察量：新副本或升配后的副本，至少跨过一次业务日高峰，MySQL可以用
SHOW REPLICA STATUS\G看Seconds_Behind_Source，PostgreSQL执行SELECT FROM pg_stat_replication;看replay_lag，确认延迟稳定在可接受范围。 - 缓存与连接预热量：新副本的buffer pool是冷的，直接接流量会出现大量物理读，提前跑预热脚本，把热点表刷进内存，连接池上限也要同步调大。
这三个提前量叠起来,基本就是3到7天，业内专家指出，大促扩容出问题的案例里，相当一部分不是规格选小了，而是扩得太晚，没留出纠错空间。
只读副本扩容和读写分离扩容哪个更划算
这两条路经常被拿来比较,其实解决的不是同一个问题，只读副本扩容是“加物理通道”，读写分离改造是“把流量引对通道”。
两条路线的成本与收益对比
| 路线 | 主要动作 | 见效速度 | 适合场景 | 隐性成本 |
|---|---|---|---|---|
| 只读副本横向加实例 | 新增只读实例、挂到代理或中间件 | 快，小时级 | 读QPS线性增长、查询可分散 | 多一份存储与备份费用 |
| 只读副本纵向升配 | 提升单副本CPU内存规格 | 较快，需重启 | 单条大查询吃资源、副本数量不便增加 | 升配窗口有短暂不可用 |
| 应用层读写分离改造 | 改路由规则、拆查询 | 慢，天级到周级 | 读流量可分类、能改造代码 | 研发排期紧，大促前风险高 |
| 缓存前置 | 热点数据进Redis | 中等 | 重复查询多、命中率高 | 缓存一致性维护成本 |
时间紧、代码改动受限的时候，优先扩只读副本；有余力做架构优化的团队，读写分离和缓存前置的长期收益更高。
什么情况下应该先扩只读副本
- 列表页、报表页、商品详情这类读多写少的查询集中爆发。
- 已有数据库代理或中间件支持自动读写分离,加副本就能被自动纳入路由。
- 距离大促不足两周,任何改代码的方案都排不进测试窗口。
反过来,如果读流量高度集中在少数几张热点表，加十个副本也只是让十个副本一起扫同一张表，这时候该做的是缓存和查询优化。
电商大促数据库只读副本扩容方案怎么落地
方案再漂亮,落地要靠一条条可执行的动作，下面这套路径在主流云数据库上基本通用。
扩容前的准备动作
- 拉近30天的读QPS曲线和慢查询TOP榜,算出峰值读流量。
- 按“峰值读流量 ÷ 单副本承载能力”估算需要的副本数量，单副本承载能力参考压测结果，别拍脑袋。
- 检查只读副本规格与主库的差距,副本规格过低会导致回放跟不上。
- 确认应用连接池的maxActive和副本数量匹配,连接数不够，新副本等于白加。
扩容操作路径
以云厂商控制台为例,路径通常是“实例详情 → 只读实例 → 变更配置或新增只读实例”，几个必须注意的点：
- 升配一般需要重启实例,务必放在业务低峰，并提前在代理层摘除该副本。
- 大促用的临时只读副本选按量计费,活动结束后释放，避免长期闲置。
- 新增副本后要手工把它加入代理的读权重列表,不少事故就出在“实例建好了但没接进流量”。
扩容后的验证清单
- 复制延迟：连续观察至少一个业务高峰，延迟无持续攀升。
- 连接数：
SHOW STATUS LIKE 'Threads_connected';确认没有打满max_connections。 - 压测回归：用JMeter或云压测服务对新副本单独压一轮，确认响应时间达标。
- 监控告警：把新副本纳入统一监控，复制延迟、CPU、磁盘使用率的阈值提前配好。
云数据库只读副本扩容价格怎么算，预算怎么批
扩容预算是大促技术保障里最容易被追问的一环,算清楚才能批得快。
计费方式的选择
- 包年包月升配：适合大促后仍要长期保留的容量，单价低，但升上去就降不下来，容易长期浪费。
- 按量付费临时副本：适合只在大促期间存在的峰值容量，随用随释放，单价高但总支出可控。
- 存储和备份费用会跟着副本数量增长,这部分常被漏算。
预算沟通的实操建议
把预算拆成“常驻容量”和“峰值容量”两块：常驻部分走包年包月，峰值部分走按量临时实例，向财务或管理层汇报时，用“峰值持续几天 × 单价”的算法给出区间，比报一个总数更容易通过，不同地域的实例单价也有差异，一线城市机房资源紧张，临时实例要提前提交工单预留，临近大促可能申请不到。
大促只读副本扩容常见问题解答
大促前只读副本扩容要提前多久提交资源申请？
资源申请和配置变更分开算,规格变更在压测通过后即可执行，通常提前3到7天；临时实例的资源预留建议提前两周提工单，尤其在北上广深等机房资源偏紧的地域，越临近大促越难申请到合适规格。
只读副本加得越多，读性能就一定越好吗？
不一定,副本数量增加会加重主库的binlog传输压力，代理层的路由和连接管理也会成为新瓶颈，多数情况下，先把单副本规格升到位、把慢查询治理掉，再考虑横向加实例，性价比更高。
扩容之后复制延迟变大正常吗？
新副本首次同步全量数据时延迟偏大属于正常现象,通常在全量同步完成后回落，如果延迟在业务高峰持续攀升，需要检查副本规格是否偏低、大事务是否过多、主库写入是否已经接近上限。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/774582.html
