slave对比：一次迁移复盘
slave对比如果只看参数表，很难判断真实效果。本文复盘一个内容社区从单库迁移到replica架构的全过程，对比自建从库与云只读实例在成本、稳定性、延迟和维护上的差异，按步骤还原决策过程。
步骤一：确认原始问题不是写入瓶颈
案例是一家内容社区，日活约8万，MySQL单库承载帖子、评论、用户资料。高峰期后台审核和前台列表同时查询，CPU长期超过80%。团队最初想升级主库规格，但慢查询分析发现，写入占比不到20%，主要压力来自列表分页、搜索前置筛选和运营报表。因此slave对比的第一步，是确认目标为读扩展，而不是盲目加机器。
步骤二：列出两个候选方案
方案A是自建slave：用现有云主机搭MySQL replica，成本低，权限和参数可控；风险是需要团队负责复制中断、磁盘扩容和故障处理。方案B是云只读实例：价格高约35%，但内置监控、复制链路和扩容能力。两者都能分担读请求，但维护责任完全不同。
步骤三：灰度接入读流量
团队没有一次性切走全部查询，而是先把后台报表、帖子列表、非实时用户资料放到从库。登录状态、权限校验、刚发布内容的详情页仍走主库。灰度一周后，自建slave平均延迟0.8秒，报表高峰可到12秒；云只读实例平均延迟0.3秒，高峰约4秒。这个slave对比结果说明，硬件和托管链路会直接影响稳定性。
步骤四：评估成本与人力
表面看自建方案每月少花约千元，但一周内出现两次复制中断，后端需要临时排查binlog位点。云只读实例账单更高，却减少了夜间告警处理。最终团队选择云只读实例承接线上读流量，自建slave保留给测试和数据校验。这不是说自建不好，而是在人手不足时，稳定性比低价更重要。
步骤五：沉淀上线规则
复盘后团队形成三条规则：强一致查询不走从库；超过3秒延迟自动把关键接口切回主库；报表查询必须限流并错峰。这个案例的价值在于，slave对比不能只看“能不能同步”，还要看业务能否容忍延迟、团队能否处理故障、成本是否覆盖隐性人力。
推荐阅读
常见问题
slave对比时最容易忽略什么？
最容易忽略人力成本。自建方案账单低，但故障排查、升级、扩容和演练都需要持续投入。
读流量可以全部切到slave吗？
不建议。强一致读、刚写入后的查询、权限和支付相关查询应谨慎，通常保留在主库或做一致性保护。
云只读实例一定比自建slave快吗？
不一定。它通常更稳定，但性能仍取决于规格、网络、SQL质量和数据量。需要用真实流量灰度验证。