ProxySQL不继承MySQL后端权限，需手动映射账号至mysql_users表并配置mysql_query_rules实现路由与拦截；认证仅校验自身表中active=1的用户记录，密码须匹配哈希格式，default_hostgroup须有效，配置后须执行LOAD和SAVE生效。
ProxySQL 代理层本身不继承、不同步 MySQL 后端的权限，所谓“统一鉴权”不是自动发生的，而是靠你手动把后端账号结构映射到 mysql_users 表，并配合 mysql_query_rules 控制 SQL 路由与拦截——本质是两套权限体系并存，ProxySQL 只认自己表里的规则。
为什么直接连 ProxySQL 报 Access denied，但连后端 MySQL 没问题
这是最常见误判点：错误以为 ProxySQL 会自动读取后端 mysql.user。实际上它完全不查后端权限表，只校验自己 mysql_users 表中是否存在匹配的 username + password + active=1 记录。
-
password字段必须填对：MySQL 5.7+ 用authentication_string哈希值（如*6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9），不能填明文；MySQL 8.0+ 默认用caching_sha2_password，ProxySQL 仅支持mysql_native_password插件认证，得先在后端执行ALTER USER 'xxx'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd' -
default_hostgroup必须指向一个已存在的hostgroup_id（查mysql_server_groups表确认），否则即使认证通过，也会在路由阶段静默失败，日志里只显示 “Connection refused” 类似模糊提示 - 改完
mysql_users后，必须执行LOAD MYSQL USERS TO RUNTIME生效，再执行SAVE MYSQL USERS TO DISK持久化，漏掉任一环节，重启即丢失
如何让 app_user 统一连接，但按实际操作人走不同权限
这不是 ProxySQL 的能力范围，得用 MySQL 原生的 PROXY 用户机制，在后端 MySQL 开启并配置，ProxySQL 只负责把连接原样透传过去。
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 先在后端 MySQL 开启
check_proxy_users=ON（需写入 my.cnf 并重启，或动态设SET PERSIST check_proxy_users = ON） - 创建被代理用户，比如
CREATE USER 'alice'@'%' IDENTIFIED BY 'xxx'；再授权代理关系：GRANT PROXY ON 'alice'@'%' TO 'app_user'@'%'；最后FLUSH PRIVILEGES - 客户端连接时必须显式声明代理目标，例如：
mysql -uapp_user -p --proxy-user=alice；JDBC URL 加&proxyUser=alice（驱动 ≥ 8.0.22）；Python mysql-connector-python 用proxy_user='alice'参数 - 验证是否生效：登录后执行
SELECT USER(), CURRENT_USER()，前者应为app_user@client_ip，后者为alice@%——只有CURRENT_USER()决定权限上下文
想用 SQL 规则做行级/库级访问控制，该怎么做
ProxySQL 的 mysql_query_rules 只能做语句级路由、重写或阻断，无法实现真正的行级权限。但它可以配合后端 MySQL 的行级安全策略（如 MySQL 8.0+ 的 Row Level Security）或视图封装，起到前置过滤作用。
- 规则匹配基于归一化后的 SQL（
digest_text），不是原始语句。用SELECT digest_text FROM stats.stats_mysql_processlist看客户端发来的 SQL 被识别成什么样，再据此写match_digest - 若想禁止某用户查敏感表，可加 rule：
match_digest='^SELECT.*FROM[[:space:]]+sensitive_table'+destination_hostgroup=-1（丢弃）或error_msg='Access denied' - 注意
apply字段：设为1表示命中后终止匹配；设为0则继续往下找规则。顺序很重要，建议把高优先级规则（如 deny）放前面 - 规则启用后必须执行
LOAD MYSQL QUERY RULES TO RUNTIME，否则stats_mysql_query_rules.hits永远为 0
真正难的不是配规则，而是厘清责任边界：ProxySQL 不处理权限逻辑，只做流量调度；权限判定必须落在后端 MySQL 实例上。很多团队卡在“以为配了 ProxySQL 就等于统一了权限”，结果审计日志里全是 CURRENT_USER() 为 app_user，根本没法追溯到具体操作人——这时候缺的不是中间件配置，而是后端 PROXY 授权和客户端参数传递的闭环。
