MySQL代理用户是服务端身份委托机制，需开启check_proxy_users、显式授权GRANT PROXY ON 'alice'@'%' TO 'app_user'@'%'并客户端指定--proxy-user=alice，缺一不可；CURRENT_USER()返回被代理用户才表示生效。
MySQL 代理用户不是“换账号登录”，而是让一个已认证用户（如 app_user）在连接建立后，**自动切换到另一个用户的权限上下文**——所有 SQL 权限、行级策略、审计日志都按被代理者（如 alice@'%'）生效。它必须显式开启、显式授权、显式触发，漏掉任一环节就完全不生效。
必须先打开 check_proxy_users 系统变量
默认关闭，不启用就等于没配。MySQL 8.0+ 要求该变量为 ON，否则 GRANT PROXY 授权会被忽略，客户端连上去也看不到任何错误，只是 CURRENT_USER() 始终是代理者自己。
- 动态启用（重启前有效）：
SET PERSIST check_proxy_users = ON; - 永久生效：写入
my.cnf的[mysqld]段，加一行check_proxy_users=ON，然后重启 MySQL - 验证是否生效：
SELECT @@global.check_proxy_users;返回1才算成功
GRANT PROXY 语法和常见翻车点
这不是普通权限授权，不能漏引号、不能省主机名、不能靠角色间接授予。核心是“被代理用户定义”必须和 CREATE USER 语句里**字面值完全一致**。
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 正确写法：
GRANT PROXY ON 'alice'@'%' TO 'app_user'@'%'; - 错误写法：
GRANT PROXY ON alice TO app_user（报错ERROR 1410） - 错误写法：
GRANT PROXY ON 'alice'@'localhost' TO 'app_user'@'%'（即使alice在 localhost 存在，但授权时 host 不匹配就不认） - 执行完必须
FLUSH PRIVILEGES;，否则旧版 JDBC 或某些中间件读不到新记录 - 验证授权是否落库：
SELECT * FROM mysql.proxies_priv WHERE User='app_user' AND Host='%';
客户端连接时怎么触发代理？不同工具写法差异大
不是连上后再 SET，而是在 TCP 握手阶段由客户端明确声明。服务端收到 user 和 proxy_user 参数后，查 mysql.proxies_priv 表确认关系，再切换上下文。
- 命令行
mysql：mysql -uapp_user -p --proxy-user=alice（注意：不是--user=alice） - JDBC URL（驱动 ≥ 8.0.22）：
jdbc:mysql://h:3306/db?proxyUser=alice - Python
mysql-connector-python：connect(..., proxy_user='alice')（不是user='alice'） - PyMySQL / MySQLdb：不原生支持；若硬要试，需用 SUPER 权限用户连上后执行
SET SESSION proxy_user = 'alice';，生产环境禁用
验证是否真生效：别只看 USER()
USER() 返回的是“谁连进来的”，CURRENT_USER() 才是“当前以谁的身份执行”。权限、审计、RLS 全部取决于后者。这是最容易误判的地方。
- 连上后立刻执行：
SELECT USER(), CURRENT_USER(); - 预期输出：
app_user@192.168.1.100和alice@%——只有后者匹配被代理用户，才说明代理成功 - 如果
CURRENT_USER()还是app_user@%，说明前面某步失败了：变量没开、授权没刷、客户端参数写错、或被代理用户不存在/密码为空（MySQL 8.0+ 强制要求有密码）
真正难的不是配置步骤，而是理解“代理用户”和“被代理用户”之间没有密码继承、没有自动同步、也没有中间状态——它是一次性、服务端强制的身份替换。只要 CURRENT_USER() 不变成目标用户，权限就不可能切换过去，所有后续操作都在原用户上下文中执行。
