ProxySQL 不自动校验后端密码一致性，须手动确保 monitor 用户、mysql_users 表应用用户与后端 MySQL 实例三者用户名密码完全匹配，否则导致健康检测失败或连接被拒；monitor 用户需在所有后端实例存在并具备 REPLICATION CLIENT 和 PROCESS 权限，ProxySQL 仅依赖其查询 @@read_only 判断主从状态，且不解析 binlog 或 SHOW SLAVE STATUS。
ProxySQL 不会自动校验后端 MySQL 用户密码是否一致，必须手动确保 monitor 用户、mysql_users 表中应用用户、以及真实后端 MySQL 实例上的对应账户三者密码完全匹配，否则健康检测失败或连接被拒。
monitor 用户必须在所有后端 MySQL 实例上存在且权限正确
ProxySQL 依赖 monitor 用户执行 SELECT @@read_only 和 SELECT 1 来判断节点状态和只读属性。若该用户缺失、密码错误或权限不足，会导致：
- 从库被误判为可写，进入
hostgroup_id=1（写组），破坏读写分离逻辑 -
mysql_servers表中status长期为OFFLINE_HARD或反复切换 - 即使主从同步正常，ProxySQL 也会拒绝将 select 路由到从库
正确做法：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 在每个 MySQL 5.7 实例（主+所有从）上执行：
CREATE USER 'monitor'@'%' IDENTIFIED BY 'your_monitor_password';GRANT REPLICATION CLIENT, PROCESS ON *.* TO 'monitor'@'%';FLUSH PRIVILEGES; - 确认
monitor用户能连通所有节点：mysql -umonitor -pyour_monitor_password -h192.168.0.11 -P3306 -e "SELECT @@read_only;" - 在 ProxySQL 管理端设置统一凭证：
SET mysql-monitor_username='monitor';SET mysql-monitor_password='your_monitor_password';LOAD MYSQL VARIABLES TO RUNTIME;SAVE MYSQL VARIABLES TO DISK;
mysql_users 表中的应用用户需与后端 MySQL 用户一一映射
ProxySQL 的 mysql_users 表不存储真实密码，只做路由转发时的凭据透传。如果后端 MySQL 没有同名用户，或密码不一致，连接会在转发阶段直接报错 Access denied for user。
- 务必在每个后端 MySQL 实例上创建相同用户名和密码的应用账户（例如
root/123456） - 不要依赖 ProxySQL 的
default_hostgroup自动 fallback：它只决定未命中规则时的默认目标组，不解决认证失败问题 - 若使用不同用户区分读写（如
app_rw写、app_ro读），需在mysql_users中配置多条记录，并用default_hostgroup+transaction_persistent控制行为 - 验证方式：
mysql -uapp_rw -p123456 -h127.0.0.1 -P6033 -e "SELECT 1;"（应成功）mysql -uapp_rw -pwrongpass -h127.0.0.1 -P6033 -e "SELECT 1;"（应报错）
MySQL 5.7 的 read_only 是 ProxySQL 区分主从的唯一依据
ProxySQL 不解析 binlog、不查 GTID、不调用 SHOW SLAVE STATUS —— 它只依赖 monitor 用户查询 @@read_only 值来决定节点归属哪个 hostgroup_id。这意味着：
- 从库
my.cnf中必须显式配置read_only=ON（或运行时执行SET GLOBAL read_only=ON;） - 主库不能意外开启
read_only=ON，否则会被踢出写组；可通过SELECT hostgroup_id, hostname, status, read_only FROM runtime_mysql_servers;实时确认 - 双主架构下，
read_only=OFF的节点都会被归入同一写组，ProxySQL 不做冲突仲裁 —— 路由安全需靠上层业务或额外脚本保障 - 若从库因故障临时关闭复制（
Slave_SQL_Running: No），只要read_only仍为ON，ProxySQL 仍视其为合法读节点（但实际数据已滞后）
最容易被忽略的是：ProxySQL 的健康检测和路由决策完全解耦。即使 monitor 连接失败，只要之前缓存的 read_only 值没过期，它仍可能继续向一个已宕机的从库转发 select 请求 —— 所以必须定期检查 runtime_mysql_servers 中的 status 和 Uptime_s 字段，而非仅信 read_only 值。
