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瓶颈
不复杂但容易忽略。真正决定要不要主从的，不是技术能不能做，而是业务有没有这个刚需。
