主从架构需精细运营：读写分离须应用层显式标记强/最终一致性读，监控并应对主从延迟，深挖从库负载价值，确保切换可控且兜底充分。
高并发场景下，单纯依赖单台 MySQL 往往会遇到连接数打满、慢查询堆积、主库写入瓶颈等问题。采用主从架构不是“一配了之”，关键在于合理拆分读写、控制延迟、规避从库不一致风险，并配合应用层适配。下面从几个实战要点展开。
读写分离要真正落地，不能只靠中间件自动路由
很多团队引入 ShardingSphere 或 MyCat 后就认为读写分离完成了，但实际中常出现以下问题：
- 事务内强制走主库，但部分非事务性读（如日志查询、后台报表）仍被错误路由到主库，加重主库压力
- 刚写入就立即查（例如注册后跳转个人页），因主从延迟导致查不到或数据旧，引发用户投诉
- 中间件未配置从库权重或健康检查，某台从库宕机后流量未及时剔除，查询超时激增
建议：在应用层显式标记读请求类型——强一致性读（@Re
adFromMaster） 和 最终一致性读（@ReadFromSlave）；对关键链路（如订单创建后查详情）加短时重试或主动 sleep 100ms 再查；定期用 SHOW SLAVE STATUS 监控 Seconds_Behind_Master，延迟超 500ms 自动降级为读主库。
从库不止用来分担查询，更要承担特定负载
把从库当成“只读备胎”太浪费。生产中可让从库承担：
- 实时性要求低的 BI 报表查询（设置 long_query_time=5，避免干扰核心业务）
- 离线数据分析任务（用 pt-archiver 分批导出，避免锁表）
- 全文检索同步源（将 binlog 解析后推送到 Elasticsearch）
- 备份任务（
mysqldump --single-transaction --master-data=2在从库执行，不影响主库性能）
注意：所有这些操作必须关闭从库的 read_only=ON（默认开启），但务必禁止手动写入——可通过账号权限严格限制（例如只授予 SELECT + REPLICATION CLIENT）。
主从延迟不是故障，但必须有应对策略
即使网络良好、硬件均衡，DML 批量更新、大事务、从库 IO 负载高都会引发延迟。不要等报警才响应：
- 在业务层埋点：记录每条写操作的 GTID 或 binlog position，读前比对从库已执行位置
- 对敏感操作（如修改密码、支付状态变更）启用“半同步复制”（rpl_semi_sync_master_enabled=ON），确保至少一个从库落盘才返回成功
- 避免在从库执行
ALTER TABLE或OPTIMIZE TABLE，这类操作会阻塞 SQL 线程，延迟飙升
典型场景：用户改收货地址后立刻查最新地址，可先查主库缓存（如 Redis 中存一份地址摘要），命中则跳过数据库读取。
主从不是高可用终点，要考虑切换与兜底
主库宕机时，手动 or 自动切换都可能出问题：
- 切换后未校验从库是否追平 binlog，导致部分事务丢失
- 应用连接池未及时刷新 DNS 或 IP，持续往旧主库发请求（连接拒绝后大量报错）
- 新主库未调整 max_connections、innodb_buffer_pool_size 等参数，扛不住原主库的全部流量
建议：使用 MHA 或 Orchestrator 实现自动选主+VIP 切换；切换前后用 SELECT MASTER_POS_WAIT() 确认同步位点；所有应用连接串必须支持重连+失败重试，且初始连接池 size 设置为预估峰值的 1.5 倍。
主从架构本身不提升写性能，也不解决锁竞争或索引缺失问题。它只是把“读”这个可水平扩展的部分剥离开来。真正稳住高并发，得靠读写分离策略清晰、延迟感知及时、从库价值挖深、切换过程可控——这些细节没做好，再多从库也只是摆设。
