proxysql 启动后连不上 mysql 主从集群，需检查 mysql_servers 表的 hostgroup_id（主库设为0、从库设为1）、status（均为'online'）、weight、max_replication_lag 及 monitor 用户权限，并执行 load/save 操作生效配置。
ProxySQL 启动后连不上 MySQL 主从集群？检查 mysql_servers 表的 hostgroup_id 和状态
ProxySQL 不会自动识别主从角色，它只按你配置的 hostgroup_id 分发流量。常见错误是把主库和从库都塞进同一个 hostgroup_id，结果读请求打到主库、写请求也打到从库——根本没分离。
实操建议：
- 主库必须配置在
hostgroup_id = 0（默认写组），status = 'ONLINE'，且weight设得足够高（比如 1000） - 从库统一配在
hostgroup_id = 1（默认读组），status = 'ONLINE'，weight可设为 100 或按负载调整 - 务必执行
LOAD MYSQL SERVERS TO RUNTIME和SAVE MYSQL SERVERS TO DISK，否则配置不生效 - 用
SELECT * FROM mysql_servers确认max_replication_lag是否设为合理值（如 30），否则延迟大的从库仍会被选中
读写分离规则没生效？重点查 mysql_query_rules 的 match_digest 和 destination_hostgroup
ProxySQL 靠正则或 digest 匹配 SQL 来决定路由，不是靠语法解析。很多用户以为 SELECT 开头就走读组，结果发现 SELECT FOR UPDATE 也被发到从库——因为规则里只写了 ^SELECT，没排除带锁的语句。
实操建议：
- 写规则优先匹配明确的写操作：
match_digest = '^INSERT ' | '^UPDATE ' | '^DELETE ' | '^REPLACE '→destination_hostgroup = 0 - 读规则要排除干扰：
match_digest = '^SELECT ' | '^WITH '→destination_hostgroup = 1，但必须加negate_match_pattern = 1并另配一条规则拦截SELECT.*FOR UPDATE回写组 -
apply = 1必须设对，否则规则不启用；sticky_conn = 1在事务中可避免主从切换导致的报错 - 规则顺序很重要：ProxySQL 从上到下匹配，写规则必须排在读规则前面
应用连 ProxySQL 后出现 ERROR 9001 (HY000): Max connect timeout reached while reaching hostgroup 1
这不是网络不通，而是 ProxySQL 尝试连接从库时超时，通常因为从库不可达、MySQL 用户权限不足，或从库启用了 skip_networking。
实操建议：
- 先在 ProxySQL 本机用
mysql -h 从库IP -P 3306 -u proxyuser -ppass手动连，确认基础连通性和账号权限（该账号需在从库上存在，且有SELECT权限） - 检查从库的
bind_address是否为127.0.0.1（ProxySQL 无法直连），应设为0.0.0.0或具体内网 IP - ProxySQL 默认用
monitor用户轮询检测后端健康，该用户必须在所有 MySQL 实例上存在，且拥有SELECT权限（如SHOW SLAVE STATUS） - 如果从库启用了
read_only=ON，确保没误关super_read_only导致监控用户被拒绝
为什么 SELECT @@hostname 总返回同一个实例？说明流量没按预期分发
ProxySQL 的路由发生在协议层，不改写 SQL，也不做语法重写。如果你的应用用长连接 + 连接池，很可能复用了之前路由到某台从库的连接，后续查询就一直落在那台机器上——看起来像“没分离”，其实是连接复用的结果。
实操建议：
- 测试时用短连接：命令行执行
mysql -h proxysql_ip -P 6033 -u appuser -ppass -e "SELECT @@hostname"多次，观察结果是否轮转 - 在 ProxySQL 中查
SELECT * FROM stats_mysql_connection_pool，看各hostgroup下的Connections_used和ConnUsed是否有增长 - 如果读组连接数始终为 0，大概率是
mysql_query_rules没匹配上，开启mysql-query-rule-verbose = 1并查日志定位匹配失败原因 - 别依赖
@@hostname判断主从，用SELECT @@read_only更可靠，主库返回 0，从库返回 1
最常被忽略的是 monitor 用户权限和 mysql_servers 表里的 max_replication_lag：前者导致健康检查失败，后者让延迟爆炸的从库照常接读流量。这两项不调好，其他配置全白搭。
