MySQL权限检查发生在每次查询执行前
MySQL在执行每条SQL语句前，都会校验当前用户对涉及的数据库、表、列是否有对应权限（如
SELECT、
INSERT、
EXECUTE）。这个检查不是一次性加载后缓存到底层执行器的，而是实时触发权限系统（主要依赖
mysql.user、
mysql.db、
mysql.tables_priv等系统表）做多层匹配。
这意味着：权限越复杂（比如大量行级权限、大量
GRANT记录、嵌套角色），每次查询前的权限路径查找开销就越高——尤其在高并发简单查询场景下，这部分开销可能从微秒级上升到几十微秒，积少成多会成为瓶颈。
权限表过大或未优化会显著拖慢权限验证
MySQL权限系统依赖 MyISAM 引擎的系统表（如
mysql.tables_priv），而 MyISAM 不支持事务、行锁和高效索引更新。当权限记录数超过几千条（例如为每个用户单独授予上百张表的细粒度权限），
FLUSH PRIVILEGES变慢、新连接建立延迟升高、甚至
SHOW GRANTS响应变卡都可能出现。 避免为每个应用用户单独建
GRANT ... ON db1.t1, db1.t2, ..., db1.t100—— 改用
GRANT ... ON db1.*+ 应用层逻辑隔离 定期清理失效账号：
DROP USER 'old_app'@'%'，不要只靠
REVOKE留着空壳记录 不使用通配符主机名（如
'user'@'%.example.com'）过多，会强制 MySQL 做 DNS 反查或扩大匹配范围 若启用了
check_proxy_users或自定义认证插件，权限链路会进一步延长
角色（ROLE）在 8.0+ 中引入额外解析开销
MySQL 8.0 的角色机制虽提升了管理性，但每次连接初始化时需递归解析角色继承关系（
role_edges表）、合并权限、去重、再生成最终权限集。如果存在深度嵌套（A → B → C → D）、跨库角色、或角色被频繁
SET ROLE切换，这个过程会明显增加连接建立时间。
实测中，一个拥有 5 层继承、关联 20+ 权限项的角色，在 10k QPS 连接复用率低的场景下，可使平均连接耗时上升 3–8ms。建议：
角色层级控制在 2 层以内 避免在连接池短生命周期连接中频繁SET ROLE用
SHOW GRANTS FOR CURRENT_USER()验证最终权限集是否预期，防止隐式叠加导致校验路径爆炸
权限缓存与刷新行为影响实际性能表现
MySQL 会缓存部分权限结果（如全局权限、DB级权限），但表级、列级、动态权限（如
BACKUP_ADMIN）不进缓存，每次都要查表。更关键的是：
FLUSH PRIVILEGES不仅刷新内存，还会触发所有活跃连接的权限缓存失效——接下来每个连接的下一条语句都会触发一次完整权限重载，造成瞬时毛刺。
生产环境应避免高频
FLUSH PRIVILEGES；如需热更新权限，优先考虑： 用
CREATE USER/
GRANT后直接复用新连接（连接池配置
maxLifetime缩短） 对核心服务账号，提前预置最小权限集，运行期不动
GRANT监控
Performance Schema中的
events_waits_summary_global_by_event_name，关注
wait/synch/mutex/sql/LOCK_grant等等待事件是否异常飙升
权限本身不消耗CPU或IO资源，但它让每次查询都多了一次潜在的锁竞争、索引查找和字符串匹配——这些细节在吞吐量上不来时，往往最先被忽略。
