MySQL 主从复制适合读多写少、需要高可用或数据备份的场景，不是所有系统都必须用，关键看业务是否真的需要。
读写分离：缓解主库压力
当应用中查询远多于更新（比如电商商品页、内容平台列表页），可把 SELECT 请求分发到从库，主库专注处理 INSERT/UPDATE/DELETE。注意事务一致性问题——刚写入的数据可能在从库有几毫秒延迟，不适合“写后立刻查”的强一致性逻辑。
- 用中间件（如 ProxySQL、ShardingSphere）或应用层 路由 实现读写分离
- 对一致性要求高的操作（如用户登录后查订单），强制走主库
- 从库数量不宜过多，通常 1–3 台足够；再多会加重主库 IO 和网络开销
数据备份与容灾
从库可作为热备节点，在主库宕机时快速切换（需配合 MHA、Orchestrator 等 工具）。相比冷备或定时mysqldump，主从复制提供近实时的数据保护，RPO（恢复点目标）通常在秒级。
- 建议至少部署一个专用备份从库，关闭写入权限，定期校验数据一致性（用 pt-table-checksum）
- 避免在从库执行 DDL 操作；若必须，先停复制、操作完再启，防止主从结构不一致
- 跨机房部署从库时，优先选半同步复制（semi-sync），降低丢数据风险
报表与分析类业务隔离
后台统计、BI 看板、离线计算等任务往往扫描大量数据，容易拖慢线上业务。将这类查询定向到专用从库，能避免锁表、IO 争抢和慢查询影响主库响应。
- 可配置低优先级从库（如设置 low_priority_updates=ON），降低对复制延迟的影响
- 大表 COUNT、GROUP BY 类查询尽量加索引，或改用汇总表 + 定时刷新机制
- 不建议直接在从库上建复杂视图或触发器，增加维护难度和潜在风险
架构选择提醒：别为复制而复制
如果单库 QPS 不到 500、数据量小于 50GB、无异地容灾需求，主从反而增加运维成本和出错概率。小项目可先用云数据库自带高可用（如 阿里云RDS 主备）、定期快照 +Binlog 归档更轻量。
- 新项目初期建议用 GTID 模式部署主从，避免位置点（File+Position）管理混乱
- 避免级联复制（A→B→C），故障排查难、延迟叠加；优先用一主多从
- 监控不能只看 Seconds_Behind_Master，还要关注复制线程状态、网络抖动、磁盘 IO 瓶颈
不复杂但容易忽略。真正决定要不要主从的，不是技术能不能做，而是业务有没有这个刚需。
