ProxySQL 不自动同步 MySQL 后端权限,必须手动将账号、密码哈希、default_hostgroup填入mysql_users表,并配置mysql_query_rules路由规则;认证仅校验自身表中active=1的记录,密码须为authentication_string哈希值,default_hostgroup须有效,且需执行LOAD和SAVE生效。

ProxySQL 不能自动同步 MySQL 后端的权限,所谓“权限映射”必须手动完成:把后端用户账号、密码哈希、期望路由组填进 mysql_users 表,并用 mysql_query_rules 强制绑定行为——漏掉任一环节,连接就会失败或路由错乱。
为什么连 ProxySQL 报 Access denied,但直连 MySQL 没问题
因为 ProxySQL 完全不查后端 mysql.user 表。它只认自己内存+磁盘里的 mysql_users 记录:
-
username和password必须完全匹配(注意:MySQL 5.7+ 的authentication_string哈希值要原样填入,不能是明文) -
active = 1才生效,否则认证直接拒绝 -
default_hostgroup必须指向一个已存在的 hostgroup_id(查mysql_server_groups确认),否则认证通过后路由阶段静默失败,日志里只显示 “Connection refused” - 改完表后必须执行
LOAD MYSQL USERS TO RUNTIME生效,再执行SAVE MYSQL USERS TO DISK持久化,重启即丢配置
如何让 app_ro 用户只读、app_rw 用户可写
核心不是靠 ProxySQL 拦 SQL,而是靠「用户→hostgroup→后端权限」三层对齐:
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景,三层路由架构(触发词→SAD反馈→DAG编排),recall@10=96.97%。配置驱动(chains.yaml),零代码扩展。pip install skill-weave-chains 一键安装。
- 先在 MySQL 主库建
app_rw@'%',赋SELECT,INSERT,UPDATE,DELETE;从库只建app_ro@'%',且只授SELECT - 在 ProxySQL 的
mysql_users表中插入两行:app_rw的default_hostgroup=10(写组),app_ro的default_hostgroup=20(读组) - 加一条强制路由规则,防止
app_ro发写语句误入主库:INSERT INTO mysql_query_rules (rule_id,username,destination_hostgroup,active,apply) VALUES (10,'app_ro',20,1,1); - 这条规则优先级高(
rule_id=10),无条件把app_ro所有请求导向 hostgroup 20;即使它发了UPDATE,也会被转发到从库——而从库上该用户没写权限,MySQL 直接报错ERROR 1142 (42000)
读写分离规则顺序写错会导致 SELECT 被送到主库
ProxySQL 匹配 mysql_query_rules 是按 rule_id 升序扫描,遇到第一条 active=1 AND apply=1 就停止。常见翻车点:
- 兜底规则(如
match_digest='.')放在前面,导致所有语句(包括SELECT)都命中写组 正确的顺序是:先插读规则( - 正则写太宽,比如用
'SELECT'匹配,会把SELECT ... FROM user_log WHERE action='INSERT'这类也当读语句 - 规则没设
apply=1,匹配成功但不终止匹配链,继续往下扫,可能被后续更宽泛规则覆盖 - 改完规则必须执行
LOAD MYSQL QUERY RULES TO RUNTIME+SAVE MYSQL QUERY RULES TO DISK,否则重启失效
match_digest='^SELECT.*',排除 FOR UPDATE),再插写规则(match_digest='.' 或空)
真正起隔离作用的从来不是 ProxySQL 的某条规则,而是「用户账号在 ProxySQL 中的绑定 + 在 MySQL 后端的最小权限 + 规则强制路径」三者咬合。任意一环松动,比如后端给 app_ro 授了 UPDATE,那 ProxySQL 再怎么拦也没用。


















