MySQL如何实现读写分离架构_利用ProxySQL进行流量分发-mysql教程-PHP中文网

proxysql 启动后连不上 mysql 的根本原因是后端节点未正确配置：需手动插入 mysql_servers 表（主库 hostgroup_id=1、从库=2），配置 mysql_replication_hostgroups 映射写/读组，执行 load/save 持久化，并验证 runtime_mysql_servers 等运行态表。

mysql如何实现读写分离架构_利用proxysql进行流量分发

ProxySQL 启动后连不上 MySQL？检查 `mysql_servers` 表和 `mysql_replication_hostgroups`

ProxySQL 不会自动发现主从拓扑，所有后端节点必须手动注册。常见现象是客户端能连上 ProxySQL（mysql -h127.0.0.1 -P6033），但执行查询时报错 Host is down 或直接超时。

先确认后端 MySQL 实例监听地址可被 ProxySQL 主机访问（别只 telnet 3306，还要用 mysql -hxxx -P3306 -uuser -p 实测登录）
往 mysql_servers 表插入记录时，hostgroup_id 必须区分：主库设为 1（写组），从库设为 2（读组）；不能全填 0 或随意设相同值
mysql_replication_hostgroups 表必须存在且配置正确，例如：
```
INSERT INTO mysql_replication_hostgroups (writer_hostgroup, reader_hostgroup, comment) VALUES (1, 2, 'prod');
```
缺少这步，ProxySQL 就不会自动把从库标记为只读
所有变更必须执行 LOAD MYSQL SERVERS TO RUNTIME，再 SAVE MYSQL SERVERS TO DISK，否则重启即丢失

读写分离没生效？重点查 `rules` 表里的 `match_digest` 和 `destination_hostgroup`

默认情况下 ProxySQL 不做语句级路由，SELECT 全部发到 reader_hostgroup 是假象——实际取决于你是否配置了规则，以及规则是否匹配成功。

最简方案是不配 mysql_query_rules，靠 mysql_replication_hostgroups + mysql_servers 的 weight 和 status 做 hostgroup 级分发，此时所有 SELECT 自动走读组，INSERT/UPDATE/DELETE 走写组
如果加了规则，match_digest 是正则匹配 SQL 归一化后的摘要（不是原始 SQL），比如 SELECT.*FROM users 匹配不了 SELECT id,name FROM users WHERE id=?，要用 SELECT.*FROM users 这种宽泛写法或留空
destination_hostgroup 值必须与 mysql_replication_hostgroups.reader_hostgroup 一致（比如都是 2），否则规则无效
规则顺序很重要：ProxySQL 按 rule_id 升序匹配，第一条命中就终止，别把通用规则放在具体规则前面

从库延迟大时，SELECT 还在转发？用 `mysql_server_read_only` + `max_replication_lag` 控制

ProxySQL 默认只看 MySQL 的 read_only 变量判断是否可读，但主从延迟高时，从库可能已开启 read_only=ON 却还没追上，导致读到旧数据。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

在 mysql_servers 表中为每个从库设置 max_replication_lag（单位秒），比如 30；ProxySQL 会定期执行 SHOW SLAVE STATUS 并检查 Seconds_Behind_Master
当延迟超过该值，ProxySQL 自动把该从库 status 设为 OFFLINE_SOFT，不再转发流量，但保留连接池、不中断已有会话
这个机制依赖从库开启复制且 read_only=ON，否则 ProxySQL 无法识别其为从库，也不会查延迟
注意：ProxySQL 本身不触发主从切换，它只做“健康剔除”，故障恢复需外部协调或配合 MHA/Orchestrator

上线前必须验证的三个状态点：`runtime_mysql_servers`、`stats_mysql_query_rules`、`monitor` 库

ProxySQL 的配置表（main 库）和运行时状态（runtime_mysql_servers 等）是分离的，容易误以为改了就生效。

查真实生效的后端列表，必须看 SELECT * FROM runtime_mysql_servers，而不是 mysql_servers；前者才是当前路由依据
查规则命中情况，看 stats_mysql_query_rules 表的 hits 字段，为 0 说明规则完全没触发，大概率是 match_digest 写错了或没加载到 runtime
monitor 库里的 mysql_server_ping_log 和 mysql_server_read_only_log 能看到心跳和只读状态探测日志，延迟判断是否正常就靠它
别跳过 PROXYSQL ADMIN 接口（默认 6032）验证，应用连的 6033 是业务端口，出问题时得回 admin 查底层状态