mysql如何通过proxy代理层进行统一的权限鉴权_配置中间件权限映射

ProxySQL不继承MySQL后端权限，需手动映射账号至mysql_users表并配置mysql_query_rules实现路由与拦截；认证仅校验自身表中active=1的用户记录，密码须匹配哈希格式，default_hostgroup须有效，配置后须执行LOAD和SAVE生效。 ProxySQL 代理层本身不继承、不同步 MySQL 后端的权限，所谓“统一鉴权”不是自动发生的，而是靠你手动把后端账号结构映射到 表，并配合 控制 SQL 路由与拦截——本质是两套权限体系并存，ProxySQL 只认自己表里的规则。 为什么直接连 ProxySQL 报 Access denied，但连后端 MySQL 没问题 这是最常见误判点：错误以为 ProxySQL 会自动读取后端 。实际上它完全不查后端权限表，只校验自己 表中是否存在匹配的 + + 记录。 字段必须填对：MySQL 5.7+ 用 哈希值（如 ），不能填明文；MySQL 8.0+ 默认用 ，ProxySQL 仅支持 插件认证，得先在后端执行 必须指向一个已存在的 （查 表确认），否则即使认证通过，也会在路由阶段静默失败，日志里只显示 “Connection refused” 类似模糊提示 改完 后，必须执行 生效，再执行 持久化，漏掉任一环节，重启即丢失 如何让 app_user 统一连接，但按实际操作人走不同权限 这不是 ProxySQL 的能力范围，得用 MySQL 原生的 PROXY 用户机制，在后端 MySQL 开启并配置，ProxySQL 只负责把连接原样透传过去。 MySQL（Linux） MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。 下载 先在后端 MySQL 开启 （需写入 my.cnf 并重启，或动态设 ） 创建被代理用户，比如 ；再授权代理关系： ；最后 客户端连接时必须显式声明代理目标，例如： ；JDBC URL 加 （驱动 ≥ 8.0.22）；Python mysql -connector-python 用 参数 验证是否生效：登录后执行 ，前者应为 ，后者为 ——只有 决定权限上下文 想用 SQL 规则做行级/库级访问控制，该怎么做 ProxySQL 的 只能做语句级路由、重写或阻断，无法实现真正的行级权限。但它可以配合后端 MySQL 的行级安全策略（如 MySQL 8.0+ 的 Row Level Security）或视图封装，起到前置过滤作用。 规则匹配基于归一化后的 SQL（ ），不是原始语句。用 看客户端发来的 SQL 被识别成什么样，再据此写 若想禁止某用户查敏感表，可加 rule： + （丢弃）或 注意 字段：设为 表示命中后终止匹配；设为 则继续往下找规则。顺序很重要，建议把高优先级规则（如 deny）放前面 规则启用后必须执行 ，否则 永远为 0 真正难的不是配规则，而是厘清责任边界：ProxySQL 不处理权限逻辑，只做流量调度；权限判定必须落在后端 MySQL 实例上。很多团队卡在“以为配了 ProxySQL 就等于统一了权限”，结果审计日志里全是 为 ，根本没法追溯到具体操作人——这时候缺的不是中间件配置，而是后端 PROXY 授权和客户端参数传递的闭环。