sql读写分离需依赖应用层或中间件实现负载均衡，核心是读请求的智能路由策略（轮询/权重/延迟感知）、强一致性读直连主库、从库数量与角色合理划分、连接池与缓存协同优化，以及监控告警与自动故障转移闭环。
SQL读写分离本身不自动实现负载均衡，关键在于应用层或中间件如何分发读请求到多个从库。主从架构下，写操作必须走主库，读操作可分散到多个从库，但若所有读请求都打到同一个从库，反而造成新的瓶颈。
读请求的智能路由策略
应用需根据业务特点选择路由方式。简单轮询适合读请求均匀、延迟不敏感的场景；权重路由更适合从库配置差异大的环境（比如高配从库设更高权重）；基于延迟的动态路由则要求中间件能实时探测从库同步延迟，并避开延迟过高的节点。
- 避免把“所有读”无差别发给“第一个可用从库”，这等于没做负载均衡
- 对强一致性读（如刚写完立刻查），应直连主库，不参与从库负载分发
- 部分中间件（如ShardingSphere、ProxySQL）支持SQL级Hint，可显式指定走主或某从，便于关键查询精准控制
从库角色与容量的合理划分
不是从库越多越好，需结合同步机制、硬件能力与业务读压力综合评估。异步复制下，从库越多，主库的网络和IO开销越大；半同步虽提升可靠性，但会增加主库事务响应时间。
- 建议核心业务部署2–3个从库，非核心读服务（如报表、分析）可单独挂接只读从库，隔离影响
- 定期检查从库的Seconds_Behind_Master及磁盘IO等待，延迟持续超过1秒需排查慢查询或大事务
- 不同从库可承担不同类型读：一个专注高并发短查询，一个专跑定时统计类长查询，通过逻辑隔离减少资源争抢
连接池与缓存协同减负
数据库连接本身是稀缺资源，读写分离后若每个应用都维持大量到各从库的连接池，会加剧网络与内存负担。此时需配合轻量缓存降低真实DB访问频次。
- 应用侧连接池按从库实例独立配置，最大连接数不宜超过从库max_connections的60%
- 对变动不频繁的数据（如城市列表、配置项），优先走本地缓存或Redis，避免穿透到从库
- 注意缓存失效策略：主库写入后，及时清除对应缓存，防止从库延迟导致脏读被缓存放大
监控与自动故障转移闭环
负载均衡效果无法靠静态配置一劳永逸，必须依赖可观测性。重点监控项包括各从库QPS、平均响应时间、复制延迟、连接数使用率。当某个从库异常时，应自动剔除并告警，恢复后平滑加回。
- 用Prometheus + Grafana采集MySQL Exporter指标，设置延迟>5s或QPS跌零自动触发告警
- 中间件或应用网关应具备健康检查机制，例如每10秒发SELECT 1探活，连续失败3次即下线该从库节点
- 避免“全量切换”思维：单个从库故障不应导致所有读请求涌向剩余节点，需预留余量并支持分级降级（如先降级缓存，再降级主库读）
