MySQL权限检查本身开销极小，但误配会引发重试、阻塞、低效执行路径等间接性能问题；如super_priv='N'导致变量修改失败重试、缺失INDEX权限使ANALYZE TABLE被拒、仅USAGE权限需遍历所有授权表、通配符主机名加剧DNS反查与匹配耗时。
MySQL权限检查本身开销极小，但误配会导致严重性能问题
MySQL在每次执行SQL前都会做权限校验，这个过程本身很快——通常在微秒级。真正拖慢性能的，是权限配置引发的间接行为：比如因SELECT权限缺失导致应用反复重试、因PROCESS权限未开而无法用SHOW PROCESSLIST定位慢查询、或因REPLICATION SLAVE权限错误让主从延迟飙升。
哪些权限配置会直接拖慢查询执行
以下几种配置不是“慢在权限检查”，而是让MySQL被迫走低效路径：
-
super_priv = 'N'且应用尝试动态修改max_connections等全局变量时，会触发额外的元数据锁等待和失败重试 - 用户没有
INDEX权限，但应用在建表后自动执行ANALYZE TABLE，该语句会被拒绝并可能阻塞后续DDL - 只授予
USAGE权限却未显式拒绝（DENY），MySQL仍需遍历所有授权表（mysql.user、mysql.db、mysql.tables_priv等）确认无匹配规则，高并发下I/O和CPU可见上升 - 使用通配符主机名（如
'user'@'%'）且存在大量mysql.host记录时，连接认证阶段的DNS反查+权限匹配耗时增加
权限相关性能问题的排查线索
别只盯着slow_query_log，这些信号更早暴露权限配置异常：
- 状态变量
Aborted_connects持续增长，配合错误日志中Access denied for user，说明连接层权限拒绝频繁发生 -
Threads_created陡增但Threads_connected稳定，可能是应用因权限不足反复新建连接替代复用 -
Handler_read_rnd_next异常高，同时Sort_merge_passes上升，暗示因缺少FILE权限导致临时表无法写磁盘，强制内存排序退化 - 执行
EXPLAIN FORMAT=TREE时出现"Using temporary; Using filesort"但SQL本身无ORDER BY，可能是因缺少SELECT权限导致优化器误判可访问列范围
生产环境权限配置的硬性建议
性能敏感场景下，权限不是越细越好，而是要匹配真实访问模式：
- 禁用
GRANT OPTION，避免权限扩散带来的隐式元数据锁竞争 - 对只读账号，显式授予
SELECT并REVOKE所有其他权限（包括USAGE以外的默认权限），防止MySQL跳过快速路径优化 - 避免用
'user'@'localhost'和'user'@'127.0.0.1'重复建用户——MySQL会分别查两次授权表 - 升级到8.0+后，用角色（
CREATE ROLE）替代逐用户赋权，减少mysql.role_edges和mysql.default_roles的查询压力
最常被忽略的是：权限变更后不会自动刷新查询缓存，但会影响后续所有新连接的执行计划选择。哪怕只是加了个INDEX权限，也可能让优化器选中新索引，进而改变锁粒度和并发表现。
