MySQL大实例权限管理不能靠手工GRANT，因人工同步易导致漏配、错配、主从不一致等问题；必须通过ProxySQL等代理层实现统一鉴权，将权限策略与MySQL执行分离。
MySQL 大实例权限管理为什么不能靠手工 GRANT
单个 MySQL 实例用 GRANT 配权限没问题，但几十上百个实例时，人工同步账号、密码、权限会立刻失控——漏配、错配、过期不清理、主从权限不一致，都是线上事故的常规入口。更麻烦的是，DBA 换人、业务线迁移、临时提权需求，全靠 SQL 脚本+人工 review，响应慢还难审计。
真正可行的路只有一条：把权限决策逻辑抽出来，让 MySQL 只负责执行鉴权结果，不参与策略制定。
- MySQL 本身不支持跨实例统一用户目录，
mysql.user表永远是本地孤岛 -
CREATE USER和GRANT无法自动同步到其他实例，除非你写完整套分发+校验+回滚逻辑 - 基于代理层（如 ProxySQL、MySQL Router）或中间件做权限路由，本质仍是把鉴权前置，MySQL 退为纯数据节点
用 ProxySQL 实现统一鉴权的最小可行路径
ProxySQL 不是万能网关，但对「统一账号+按库/表/命令限流/拦截」这种需求，它比自研中间件轻得多，也比改 MySQL 源码现实得多。关键在于：所有客户端连的不是 MySQL，而是 ProxySQL；它查自己的 mysql_users 表做认证，再根据 mysql_query_rules 做细粒度路由和拦截。
-
mysql_users表存用户名、加密密码（USE SSL可选）、默认 hostgroup，一条记录即一个逻辑账号 - 真实 MySQL 实例只需保留极简账号（比如只给
proxy_user@'10.0.0.%'的SELECT/INSERT/UPDATE/DELETE权限），不再管业务账号 - 权限变更只需更新 ProxySQL 的
mysql_users或mysql_query_rules，热加载生效，不重启 - 注意：
mysql_users.password必须是SHA1(UPPER(HEX(SHA1(<password>))))</password>格式，直接填明文或 MySQL 8.0 的caching_sha2_passwordhash 会认证失败
INSERT INTO mysql_users (username, password, active, default_hostgroup)
VALUES ('app_rw', '7C9D4F5E2A1B0C9D8E7F6A5B4C3D2E1F0A9B8C7D', 1, 10);
MySQL 8.0+ 的缓存 SHA2 密码与统一鉴权的冲突点
MySQL 8.0 默认用 caching_sha2_password 插件，它的密码 hash 是服务端生成的，且依赖 RSA 加密交换盐值。ProxySQL 5.x 目前不支持该插件的完整握手流程，直连会报 Plugin caching_sha2_password could not be loaded 或认证超时。
- 最稳方案：在 MySQL 实例侧显式降级用户认证插件：
ALTER USER 'proxy_user'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; - 不要试图让 ProxySQL 支持
caching_sha2_password——它没内置 OpenSSL，也没做密钥协商，强行启用只会卡在 Auth Switch Request - 如果必须保 SHA2，只能用连接池模式（如 PGBouncer 类思路），但 MySQL 没官方连接池，得靠应用层或额外组件兜底，复杂度陡增
权限变更后如何验证是否真正生效
改完 ProxySQL 配置，别急着通知业务。MySQL 层面的权限缓存（FLUSH PRIVILEGES）不影响 ProxySQL，但 ProxySQL 自己有两层缓存要清：内存配置和磁盘持久化。
- 先运行
LOAD MYSQL USERS TO RUNTIME，让新用户立即可用；再SAVE MYSQL USERS TO DISK，防止重启丢失 - 验证时用真实客户端连 ProxySQL 端口（非 MySQL 端口），执行
SELECT USER(), CURRENT_USER();——前者是登录名，后者是 ProxySQL 映射后的后端账号，二者不同才说明鉴权已介入 - 最容易漏的坑：忘记在
mysql_servers表里把后端实例的max_replication_lag设合理值，主从延迟大时，ProxySQL 可能把读请求错误打到延迟高的从库，导致权限规则误判（比如某规则只允许读主库）
