MySQL权限检查在每次查询前实时进行，依赖mysql.user等系统表多层匹配，权限越复杂开销越高；MyISAM权限表在记录过多时性能下降；角色嵌套过深、高频FLUSH PRIVILEGES等均会显著增加延迟。
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资源，但它让每次查询都多了一次潜在的锁竞争、索引查找和字符串匹配——这些细节在吞吐量上不来时，往往最先被忽略。
