MySQL集群需借助外部组件实现读写分离，推荐ProxySQL或MaxScale代理方案，兼顾灵活性与稳定性；客户端方案侵入业务，DNS/VIP方案不适用于主从读写分离。
MySQL集群本身不自带负载均衡能力，需要借助外部组件实现读写分离和流量分发。核心思路是：写请求全部打到主节点，读请求按策略分发到多个从节点，从而提升整体吞吐和可用性。
基于代理层的负载均衡（推荐）
在应用和MySQL之间插入一个智能代理，由它解析SQL、判断读写类型，并路由到对应节点。这是最常用也最灵活的方式。
- ProxySQL：轻量、高性能、支持动态配置和SQL重写，能自动剔除故障从库，还能做连接池和查询缓存；适合中大型业务。
- MaxScale：MariaDB官方出品，功能完整，支持读写分离、负载均衡、防火墙等；配置稍复杂，但稳定性好。
- MySQL Router：Oracle官方提供，轻量易集成，适合InnoDB Cluster生态，但功能较基础，不支持复杂路由规则。
基于客户端的读写分离
由应用代码或数据库驱动直接控制连接逻辑，比如用ShardingSphere-JDBC、MyBatis Plus多数据源插件，或自定义DataSource路由。
- 优点是无需额外中间件，部署简单；
- 缺点是逻辑侵入业务，升级维护成本高，且无法统一管理连接和故障转移。
- 适合小规模或对延迟极度敏感、需精细控制路由的场景。
基于DNS或VIP的简单分发（不推荐用于读写分离）
用Keepalived+LVS或DNS轮询把流量打到多个MySQL实例，但这类方案无法识别SQL语义，容易把写请求误发到从库导致报错。
- 仅适用于只读集群（如报表库），且所有节点数据完全一致；
- 不能用于主从架构下的常规读写分离；
- 缺乏健康检查和自动故障转移能力，运维风险高。
关键注意事项
无论选哪种方案，都要注意几个实际问题：
- 主从延迟影响读一致性：读从库前可加延迟阈值判断，或对强一致性读强制走主库（如用/*FORCE_MASTER*/注释标记）。
- 节点健康探测必须开启：ProxySQL和MaxScale都支持心跳检测，避免把请求发到已挂掉的从库。
- 连接数与超时要调优：代理层默认连接池大小、后端连接超时、SQL执行超时等参数，需根据实际QPS和慢查比例调整。
- 监控不可少：重点关注各从库延迟、代理转发成功率、后端连接数、慢查询分发路径等指标。
不复杂但容易忽略。选型优先考虑ProxySQL或MaxScale，配合合理的读写策略和监控，就能稳住大部分MySQL集群的流量分发需求。