如何部署MySQL的读写分离环境？-mysql教程-PHP中文网

读写分离不能仅依赖主从配置，必须明确路由主体、应对主从延迟、识别强一致读场景；proxysql是可控中间件，需正确定义mysql_servers和mysql_query_rules，且应用层须对“写后立即读”提供强制走主库的兜底机制。

如何部署mysql的读写分离环境？

直接上结论：读写分离不是配完主从就能用的，必须明确由谁做路由、怎么应对主从延迟、以及哪些读必须走主库——否则上线后大概率出现“刚下单查不到订单”这类问题。

主从复制必须先跑通，且不能只看`Seconds_Behind_Master`

很多团队卡在这一步：明明SHOW SLAVE STATUS\G里Seconds_Behind_Master显示为0，但应用一连就报错或数据不一致。原因通常是：

主库没开log-bin或server-id重复，导致从库根本没同步任何日志
从库read_only=ON没生效，人为写了数据，后续复制冲突
用了MIXED或STATEMENT binlog 格式，遇到NOW()、UUID()等非确定函数导致从库执行结果不同
Seconds_Behind_Master在高负载下可能不准，更可靠的是用GTID比对Executed_Gtid_Set和Retrieved_Gtid_Set

建议：主库配置强制binlog-format=ROW，从库启动后立即执行STOP SLAVE; START SLAVE;并观察Slave_IO_Running和Slave_SQL_Running是否都为Yes。

ProxySQL 是目前最可控的中间件选型，但规则写错就全走错

用ProxySQL做路由，核心是两张表：mysql_servers定义节点，mysql_query_rules定义分发逻辑。常见错误包括：

把主库和从库都塞进同一个hostgroup_id，结果所有请求都打到同一组节点
规则match_digest写成'^SELECT'，漏掉select小写、带换行或空格的SQL，导致部分读请求仍走主库
没加SELECT ... FOR UPDATE的单独规则，这类语句本质是写操作，必须路由到主库，否则会锁错行甚至死锁
没设apply=1，规则加载后不生效；或者忘了执行LOAD MYSQL QUERY RULES TO RUNTIME和SAVE MYSQL QUERY RULES TO DISK

推荐最小可用规则集：

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup, apply) VALUES
(1, 1, '^SELECT.*FOR UPDATE', 10, 1),
(2, 1, '^INSERT|^UPDATE|^DELETE|^REPLACE|^CREATE|^ALTER|^DROP|^CALL', 10, 1),
(3, 1, '^SELECT', 20, 1);