ProxySQL不自动映射MySQL后端权限，需手动配置mysql_servers、mysql_users（password填authentication_string哈希值，active=1，default_hostgroup须有效）、mysql_query_rules三表协同生效，缺一不可。
ProxySQL 本身不转发或映射 MySQL 后端权限，所谓“前端权限分发”必须靠手动配置三张表协同完成：mysql_servers（后端节点）、mysql_users（前端账号→默认路由组）、mysql_query_rules（SQL行为拦截与重定向）——漏掉任一环节，权限控制就失效。
mysql_users 表里 password 字段填什么？
填 MySQL 后端用户的 authentication_string 哈希值，不是明文密码，也不是旧版 Password 字段值。MySQL 5.7+ 默认用 caching_sha2_password 插件，哈希长度为 60 位（如 $A$...xyz）。直连 MySQL 查：
SELECT User, Host, authentication_string FROM mysql.user WHERE User = 'app_ro';
复制该字段完整值，插入 mysql_users 表的 password 列。若填错，ProxySQL 认证直接报 Access denied for user，且日志里不会提示哈希格式问题。
- active = 1 才生效，否则连接被静默拒绝
- default_hostgroup 必须对应一个已存在的 hostgroup_id（查
mysql_server_groups确认） - 改完必须执行
LOAD MYSQL USERS TO RUNTIME，再SAVE MYSQL USERS TO DISK，否则重启丢失
怎么让 app_ro 用户只读、app_rw 用户可写？
核心不是 ProxySQL 拦 SQL，而是「用户→hostgroup→后端权限」三层对齐。不能只靠规则，后端 MySQL 账号本身权限必须严格区分：
立即学习“前端免费学习笔记（深入）”；
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 在 MySQL 主库上建
app_rw@'%'，只授SELECT, INSERT, UPDATE, DELETE；从库上只建app_ro@'%'，且仅授SELECT - 在
mysql_users中，app_rw的default_hostgroup = 10（主库组），app_ro的default_hostgroup = 20（从库组） - 加一条强制路由规则防误写：
INSERT INTO mysql_query_rules (rule_id,username,destination_hostgroup,active,apply) VALUES (10,'app_ro',20,1,1);
这条规则优先级高，把 app_ro 所有语句都导向从库；即使它发了 UPDATE，也会被 MySQL 从库自己拒绝（报 ERROR 1142 (42000)），ProxySQL 不做语法拦截。
mysql_query_rules 匹配失败导致读写分离失效？
ProxySQL 只按正则匹配 SQL 文本，不解析 AST。常见失效点全是大小写和边界问题：
- 规则写
'^SELECT'，但应用发的是select * from t（小写）→ 不匹配。应改用'^select\b'并设case_sensitive=0 - 规则写
'SELECT.*FOR UPDATE'，但语句含换行或注释 → 正则断开。建议用'^select.*for update$'加case_sensitive=0和apply=1 - 规则顺序错：兜底规则（如
match_digest='.'）放在前面，所有语句都被送到default_hostgroup→ SELECT 也走主库
验证是否命中：查 stats_mysql_query_rules 表的 hits 字段。没增长，说明正则根本没触发。
为什么改了规则还是连不上或路由错？
ProxySQL 配置是三层分离的：内存（RUNTIME）←→ 内存快照（MEMORY）←→ 磁盘（DISK）。你 INSERT 的只是 MEMORY 层，不 LOAD 就不会生效，不 SAVE 就不会持久。最容易被忽略的是：
- 改
mysql_servers后忘了LOAD MYSQL SERVERS TO RUNTIME→ 连接后端时直接超时或报Unknown MySQL server host - 改
mysql_query_rules后只LOAD没SAVE→ 重启 ProxySQL 后规则全丢 - 多个规则
rule_id冲突或apply=0→ 表面插入成功，实际不参与匹配
复杂点在于：路由行为取决于 mysql_users.default_hostgroup + mysql_query_rules + transaction_persistent 三者叠加，事务中发的第二条 SELECT 可能仍走主库，哪怕它匹配了读规则。
