一主多从MySQL读写分离的核心是写走主库、读分发从库，依赖复制保持最终一致；需配置主从参数、选择路由方式（中间件/应用层/客户端代理）、应对延迟/只读绕过/单点故障，并持续监控验证。
一主多从 MySQL 读写分离的核心是：写操作全部走主库（Master），读操作分散到多个从库（Slaves），通过复制机制保持数据最终一致。配置本身不难，但关键在路由控制、复制稳定性、延迟监控和故障切换设计。
1. 搭建一主多从复制架构
确保主库开启 binlog，从库开启 relay log，并配置唯一 server-id：
-
主库 my.cnf 配置：
log-bin = mysql-bin
binlog-format = ROW
server-id = 1
skip-slave-start = 1 -
每个从库 my.cnf 配置（server-id 必须唯一）：
server-id = 101 # 如 slave1
relay-log = mysql-relay-bin
read_only = 1 # 防止误写 - 在主库执行
SHOW MASTER STATUS;记下 File 和 Position；
在各从库执行：
CHANGE MASTER TO
MASTER_HOST='主库IP',
MASTER_USER='repl',
MASTER_PASSWORD='xxx',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154;
START SLAVE; - 用
SHOW SLAVE STATUS\G检查Slave_IO_Running和Slave_SQL_Running是否为 Yes，Seconds_Behind_Master接近 0
2. 实现读写分离的常见方式
MySQL 本身不内置读写分离逻辑，需借助外部组件或应用层控制：
Difeye-敏捷的轻量级PHP框架
下载
Difeye是一款超轻量级PHP框架，主要特点有： Difeye是一款超轻量级PHP框架，主要特点有： ◆数据库连接做自动主从读写分离配置，适合单机和分布式站点部署； ◆支持Smarty模板机制，可灵活配置第三方缓存组件； ◆完全分离页面和动作，仿C#页面加载自动执行Page_Load入口函数； ◆支持mysql，mongodb等第三方数据库模块，支持读写分离，分布式部署； ◆增加后台管理开发示例
-
中间件方案（推荐初学者/中小规模）：
使用 ProxySQL 或 MaxScale。以 ProxySQL 为例：
– 配置主库为 writer hostgroup（如 hg 10），从库加入 reader hostgroup（如 hg 20）；
– 设置规则：INSERT/UPDATE/DELETE 路由到 hg 10，SELECT 默认走 hg 20；
– 支持自动剔除延迟过大或宕机的从库（通过mysql_servers表 + 监控脚本） -
应用层路由（灵活但开发成本高）：
– 在 DAO 层或 ORM（如 MyBatis、Spring Boot + AbstractRoutingDataSource）中判断 SQL 类型或方法注解（@ReadOnly）；
– 连接池按角色区分：writeDataSource / readDataSource（可配置多个 read 数据源做负载）；
– 注意事务内所有操作必须走主库（否则读到旧数据） -
客户端代理（轻量级）：
如使用 ShardingSphere-JDBC，通过 YAML 配置数据源和读写分离规则，无中心节点，对应用透明
3. 关键问题与应对策略
实际运行中容易忽略但影响稳定性的问题：
-
主从延迟导致读到旧数据：
– 对一致性要求高的查询（如订单提交后立即查详情），强制走主库（可加 Hint 或标记 @StrongConsistency）；
– 从库延迟监控：定期查Seconds_Behind_Master，超阈值（如 > 3s）时临时摘除该从库；
– 避免大事务、长更新、全表 UPDATE，这些会加剧复制延迟 -
从库只读被绕过：
– 确保从库设置read_only=1，且普通账号无 SUPER 权限（SUPER 可绕过 read_only）；
– 生产环境禁用 root 远程登录，创建专用复制账号和应用账号并严格授权 -
单点故障与高可用：
– 主库宕机需人工或自动化切换（如 MHA、Orchestrator、Replication Manager）；
– 切换后需重配从库指向新主库，中间件也需同步更新后端列表；
– 建议至少部署 3 个节点（1 主 2 从），避免脑裂
4. 验证与日常维护要点
上线前务必验证，运行中持续观察：
- 写入主库后，立刻在各从库执行相同 SELECT，确认数据及时同步；
可用SELECT SLEEP(1); SELECT @@hostname, NOW(), (SELECT COUNT(*) FROM test.t1);快速比对 - 压测时关注从库 CPU、IO、复制线程状态，避免 SQL 线程成为瓶颈（MySQL 5.7+ 可开启
slave_parallel_workers） - 定期检查复制错误（
Last_IO_Errno/Last_SQL_Errno）、慢日志、连接数、主从 binlog 文件增长是否异常 - 备份策略：建议只在从库上做物理备份（xtrabackup），避免影响主库性能
