读写分离核心是写操作固定发主库、读操作分发至从库，前提是主从通过binlog（推荐row格式）可靠同步；需配置server-id、relay log、read_only，并借助应用层、连接池或代理层（如proxysql、mycat）实现路由，同时应对延迟、单点失效与从库过载问题。
实现数据库读写分离，核心是把写操作（INSERT/UPDATE/DELETE）固定发往主库，读操作（SELECT）分发到一个或多个从库，前提是主从数据已通过复制机制保持同步。关键不在“能不能分”，而在于“怎么分得稳、分得准、分得及时”。
主从复制是前提，不是可选项
没有可靠的数据同步，读写分离就失去意义。MySQL 主从复制依赖 binlog 实现：
- 主库开启 binlog（格式推荐 ROW），设置唯一 server-id
- 从库配置 server-id（不能与主库重复），启用 relay log，并设 read_only = 1 防止误写
- 主库创建专用复制用户，授权 REPLICATION SLAVE
- 从库执行 CHANGE MASTER TO，指定主库地址、binlog 文件名和位置（来自
SHOW MASTER STATUS） - 启动复制后，用
SHOW SLAVE STATUS\G确认 Slave_IO_Running 和 Slave_SQL_Running 均为 Yes
路由方式决定落地复杂度
读写请求如何分配，有三种主流路径：
- 应用层路由：在代码中显式区分数据源，比如 Spring Boot + MyBatis 可结合 AbstractRoutingDataSource 动态切换主/从数据源；适合中小项目，控制力强但侵入业务逻辑
- 连接池级路由：如 HikariCP 配置两个独立数据源（一个连主库、多个连从库），由上层逻辑决定使用哪个连接池；轻量、无需中间件，但需自行处理负载均衡与故障转移
- 代理层路由：用 ProxySQL、MySQL Router 或 MyCat 等中间件接收统一入口请求，自动识别 SQL 类型并转发——写走主库，读走从库集群；对应用透明，支持读负载均衡、延迟感知、自动剔除异常节点，适合中大型系统
必须正视的现实问题
读写分离不是一配就灵，几个典型痛点要提前设计应对策略：
- 主从延迟：异步复制下，从库可能滞后几毫秒到几秒。刚写完立刻查，容易读到旧数据。解决方案包括：强制走主库查（如订单创建后立即查详情）、设置从库延迟阈值自动降级、或改用半同步复制降低延迟概率
- 单点失效：主库宕机，整个写链路中断。需配合高可用方案，如 MHA、Orchestrator 或 MySQL InnoDB Cluster，实现故障自动检测与主从切换
- 从库过载：所有读都压到一个从库？应部署一主多从，并在路由层做简单轮询或权重分配；ProxySQL 还支持按响应时间动态调整流量
MySQL 8.2+ 的新选择：InnoDB ReplicaSet + Router
如果你用的是 MySQL 8.2 或更新版本，官方提供了更集成的方案：部署 InnoDB ReplicaSet，再搭配 MySQL Router。Router 能自动识别读写语句，将写请求定向至当前主实例，读请求分散到健康从实例。配置比自建代理简单，且原生支持故障感知和自动重路由，适合希望减少运维负担的团队。
