proxysql 启动后连不上 mysql 是因未正确配置 mysql_servers 和 mysql_replication_hostgroups 表：需手动插入 mysql 实例并设 hostgroup_id=0（写）/1（读），且 mysql_replication_hostgroups 必须唯一配置 writer=0、reader=1；配置后须执行 load to runtime 和 save to disk。
ProxySQL 启动后连不上 MySQL？检查 mysql_servers 表和 mysql_replication_hostgroups
ProxySQL 不是开箱即用的“自动发现”中间件，它不会自己识别主从关系。你得手动把后端 MySQL 实例加进 mysql_servers 表，并明确标出哪个是写组（hostgroup_id = 0）、哪个是读组（hostgroup_id = 1），再通过 mysql_replication_hostgroups 表告诉 ProxySQL “0 是写，1 是读，靠 Read_only 状态自动切”。
常见错误现象：ERROR 9001 (HY000): ProxySQL Error: unable to find a server matching the hostgroup，基本就是 mysql_servers 没插、插错 hostgroup_id，或者 mysql_replication_hostgroups 没配或配反了。
- 确保每个 MySQL 实例在
mysql_servers中有且仅有一条记录，status='ONLINE'，weight非零 -
mysql_replication_hostgroups必须且只能有一行：writer_hostgroup=0，reader_hostgroup=1，comment='read/write split' - 执行完 INSERT 后别忘了
LOAD MYSQL SERVERS TO RUNTIME和SAVE MYSQL SERVERS TO DISK
为什么 SELECT 不走读组？看 mysql_query_rules 的 destination_hostgroup 和 apply 顺序
ProxySQL 路由 SELECT 到读组，不是靠语法猜，而是靠规则匹配。默认规则不生效，必须显式插入一条匹配 SELECT 的规则，并指定 destination_hostgroup=1。而且规则按 rule_id 升序匹配，第一条命中就结束，apply=1 才终止后续匹配。
常见错误现象：所有流量都打到 hostgroup 0（写组），SHOW STATS STATS_mysql_connection_pool 显示 hg=1 的连接数始终为 0。
- 插入规则示例：
INSERT INTO mysql_query_rules(rule_id,active,match_digest,destination_hostgroup,apply) VALUES(1,1,'^SELECT',1,1) - 如果已有
rule_id=0匹配所有语句并指向hg=0，新规则得设rule_id > 0且apply=1，否则被拦截在前 - 注意大小写：
match_digest默认区分大小写，'^select'不会匹配SELECT，建议用'^SELECT'或启用case_sensitive=0
主从延迟大时，SELECT 还可能读到旧数据？ProxySQL 本身不校验延迟，得靠 mysql_server_read_only 和监控联动
ProxySQL 只看 MySQL 实例返回的 Read_only 系统变量来判断是否可读，它不查 Seconds_Behind_Master。也就是说，即使从库延迟 30 秒，只要 Read_only=ON，它就照常转发 SELECT 过去。
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
这不是 bug，是设计使然——延迟判断逻辑复杂、开销高，不在 ProxySQL 职责范围内。真要规避延迟读，得靠外部手段干预。
- 定期脚本查从库延迟，若
Seconds_Behind_Master > 30，就动态执行UPDATE mysql_servers SET status='OFFLINE_SOFT' WHERE hostgroup_id=1 AND hostname='xxx' - ProxySQL 8.0+ 支持
mysql_server_connect_error监控，但不包含复制延迟指标 - 应用层更稳妥：对一致性要求高的 SELECT，显式加
/*+ MAX_EXECUTION_TIME(1000) */并捕获超时，触发重试或降级
配置改完没生效？别只 reload config，Runtime 和 Disk 两层状态必须同步
ProxySQL 有三层配置模型：MEMORY（当前运行态）、RUNTIME（生效但未落盘）、DISK（持久化）。你在 Admin 界面或 mysql -uadmin 里做的 INSERT/UPDATE，只是改了 MEMORY；必须 LOAD xxx TO RUNTIME 才真正生效；再 SAVE xxx TO DISK 才保证重启不丢。
最容易被忽略的一点：修改 mysql_query_rules 后只执行 LOAD MYSQL QUERY RULES TO RUNTIME，却漏了 SAVE，结果 ProxySQL 重启后规则全空，业务瞬间全打主库。
- 典型操作链：
INSERT INTO mysql_query_rules ...→LOAD MYSQL QUERY RULES TO RUNTIME→SAVE MYSQL QUERY RULES TO DISK - 检查是否生效：
SELECT * FROM runtime_mysql_query_rules（看 RUNTIME 层），SELECT * FROM disk.mysql_query_rules（看 DISK 层） - 如果改的是用户或变量，对应的是
mysql_users和global_variables表，同样要 LOAD + SAVE
ProxySQL 的读写分离不是开关一开就稳的，它的每条路由决策都依赖你填对的表、写准的规则、同步到位的状态。最常出问题的地方，往往不是语法写错，而是 MEMORY/RUNTIME/DISK 三者没对齐，或者以为它能自动感知延迟。
