MySQL读写分离是将写操作交主库、读操作分发至从库的分流策略，旨在减主库压力、提升并发与扩展性；依赖主从同步（binlog+I/O线程拉取relay log+SQL线程重放），默认异步存在延迟，可选半同步或并行复制优化；路由方式有应用层（侵入性强）和中间件（业务无感但链路长）；需应对延迟读旧、从库负载不均、主库单点三大问题；不同于分库分表，它不解决容量瓶颈，二者可叠加但应依监控审慎实施。
MySQL读写分离，核心就是把写操作（INSERT、UPDATE、DELETE）全交给主库，读操作（SELECT）尽量分发到一个或多个从库上。本质不是“完全隔离”，而是有策略地分流，目标明确：减主库压力、扛更高并发、支撑业务横向扩展。
主从同步是读写分离的前提
没有可靠的数据同步，读写分离就失去意义。主库通过 binlog 记录所有变更，从库靠两个关键线程完成同步：
- I/O 线程：连接主库，拉取 binlog 内容，写入本地 relay log
- SQL 线程：读取 relay log，重放 SQL，更新从库数据
默认异步复制下，从库必然存在延迟——刚写进主库的订单，可能几十毫秒后才在从库可见。这是设计使然，不是故障。若对实时性要求高，需考虑半同步复制（至少一个从库确认接收 binlog 才算事务成功）或并行复制（多线程回放，缓解单表写入瓶颈）。
读写请求怎么路由？两种主流方式
应用层路由：代码里显式指定数据源，比如用注解 @Read 或 @Write，或基于方法名自动识别（如 selectXXX 走从库，updateXXX 走主库）。优点是灵活、可控、无额外组件；缺点是侵入性强，容易误配，主库切换时要批量改配置或重启服务。
中间件路由：引入 ProxySQL、MaxScale、MySQL Router 等代理层。应用只连中间件，由它判断语句类型、负载、延迟等，自动转发。好处是业务无感、统一管控、支持故障自动切换；代价是链路变长、多一个运维点、需关注中间件自身可用性与性能。
必须正视的三个现实问题
主从延迟导致读到旧数据：用户刚下单，立刻查订单列表却查不到。常见应对包括：
- 关键读强制走主库（如订单创建后立即查询）
- 引入“读后写一致性”机制（例如把用户会话绑定到刚写过的节点）
- 业务接受短暂延迟，前端加 loading 或提示“数据稍后同步”
从库负载不均：所有读请求都打到同一台从库，它先扛不住。解决靠中间件内置负载策略（轮询、权重、响应时间加权）或应用层做连接池分级。
主库单点风险：主库宕机，写服务中断。仅靠主从不够，需配合高可用方案，如 MHA、Orchestrator 自动选主，或升级为 MySQL Group Replication 实现多主自动容灾。
它和分库分表不是一回事
读写分离解决的是“读多写少”场景下的负载分担，不改变单库容量上限；分库分表解决的是单库数据量过大、QPS 过高带来的性能瓶颈，属于水平拆分。两者可叠加使用：先做读写分离稳住读压，再按业务维度分库分表突破写瓶颈。但切记——过度设计比不设计更危险，先看监控指标（主库 CPU、QPS、慢查、复制延迟），再决定是否上。
