主从复制解决读多写少的流量压力
当业务中
SELECT请求远高于
INSERT/
UPDATE/
DELETE，比如电商商品页、内容平台详情页、报表后台查询，单库扛不住并发读请求。主从复制让写操作只走
master，读请求分发到一个或多个
slave，实际是把读吞吐横向扩展了。
注意：应用层必须显式区分读写路由，MySQL 本身不自动做这个决策。常见做法是用中间件（如
ShardingSphere、
ProxySQL）或在 ORM 层（如
MyBatis的
AbstractRoutingDataSource）做数据源切换。 不能把所有读都扔给从库——比如刚插入一条订单，紧接着查这条记录，若查从库可能因复制延迟还没同步，导致“查不到” 强一致性读必须打到主库，或等待
MASTER_POS_WAIT()确认位点已同步 从库数量不是越多越好，每个从库都会增加主库的二进制日志解析和网络开销
从库承担备份与高可用切换任务
主从结构天然提供一份实时热备。当
master故障时，可快速提升某个
slave为新主库（需配合
GTID+
semi-sync避免数据丢失）。但注意：这不属于“自动故障转移”，MySQL 原生不提供集群管理能力，必须依赖外部工具（如
Orchestrator、
MHA或云厂商的 RDS 自动主从切换）。
典型误操作是直接在从库执行
STOP SLAVE; RESET SLAVE ALL;后就当它是新主库——没清理 relay log 位点、没重置 GTID_EXECUTED，后续再挂回原主库可能引发事务重复或跳过。 生产环境务必开启
gtid_mode=ON和
enforce_gtid_consistency=ON从库应关闭
binlog（除非它还要当其他实例的主库），否则会额外写日志并影响性能 监控项不能只看
Seconds_Behind_Master，它在空闲或大事务时可能为
0却实际卡住；更可靠的是比对
SHOW MASTER STATUS和
SHOW SLAVE STATUS中的
Exec_Master_Log_Pos与
Read_Master_Log_Pos
从库用于离线分析与报表生成
跑复杂聚合查询（如
GROUP BY+ 多表
JOIN+ 全表扫描）会严重拖慢主库响应。把这类低优先级、允许分钟级延迟的任务定向到专用从库，是最小成本的资源隔离方案。
关键点在于避免影响线上服务：专用从库建议配置更低规格（CPU/内存），并设置
max_execution_time限制长查询，同时开启
read_only=ON防止误写。 不要在报表从库上建索引优化——主库 DDL 不会同步到从库，且索引会影响复制性能 如果报表 SQL 需要访问大量历史归档数据，考虑用
mysqldump导出后导入独立分析库，而不是长期占用一个从库实例 某些 BI 工具（如 Tableau）默认启用连接池并复用连接，若未配置只读模式，仍可能把写语句发到从库导致报错
ERROR 1290 (HY000): The MySQL server is running with the --read-only option
跨机房容灾与地理就近读
主库放在北京 IDC，从库部署在上海或深圳，用户请求按 DNS 或负载均衡就近接入本地从库，降低跨城网络延迟。这种架构下，复制链路变成跨公网或长距专线，
network latency成为最大瓶颈。
此时必须调优：增大
slave_net_timeout（默认 60 秒，长距易超时断连），启用
slave_compressed_protocol=ON减少带宽占用，并强烈建议用
semi-sync replication避免主库提交后长时间不知道从库是否收到。 不要在跨机房场景下依赖
async replication做强一致容灾——网络抖动时主库可能已提交，但从库一条没收到 从库所在机房若发生整体故障，仅靠主从无法自动恢复服务；真正容灾需要多活设计或单元化拆分
CHANGE MASTER TO ... MASTER_SSL=1必须开启，否则复制账号密码等敏感信息明文传输 主从复制不是银弹。它缓解读压力、提供基础冗余，但解决不了分片、分布式事务、全局一致性这些分布式核心问题。最容易被忽略的是：复制延迟在任何规模下都存在，而业务代码里那些“先写后读”的隐含假设，往往比数据库配置更容易引发线上故障。
