一主多从 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 本身不内置读写分离逻辑，需借助外部组件或应用层控制：
中间件方案（推荐初学者/中小规模）：使用 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），避免影响主库性能
