MySQL高并发下mysql.user表查询慢会拖垮连接建立，因每次连接、SET ROLE或权限函数调用均需查询该表；若引擎为MyISAM、未启用skip_name_resolve或存在DNS解析阻塞，将引发表级锁或延迟瓶颈。
MySQL 权限认证缓存本身不可手动预热或显式控制，所谓“命中率优化”本质是减少权限校验触发频次、缩短单次校验路径——不是缓存本身的问题，而是系统表查询和线程上下文重建的开销问题。
为什么mysql.user查得慢会拖垮高并发连接建立？
每次 TCP 连接建立、执行 SET ROLE、调用 IS_ROLE_IN_SESSION() 或 CURRENT_ROLE() 时，MySQL 都会隐式查询 mysql.user、mysql.role_edges 等系统表，并重建线程级权限缓存。在每秒数千连接的场景下，这些查询若未走主键、或因引擎为 MyISAM 触发表级锁、或受 DNS 解析阻塞，就会形成明显瓶颈。
- 确认
mysql.user使用 InnoDB：执行SHOW TABLE STATUS FROM mysql LIKE 'user';，Engine 字段必须是InnoDB（5.7+ 默认，但升级后可能残留 MyISAM） - 禁用无关认证插件：如非本地环境却启用了
auth_socket，每次登录都要解析plugin字段并加载对应逻辑，增加开销 - 关闭反向 DNS 解析：确保
skip_name_resolve=ON，否则GRANT ...@'host'中的 hostname 会触发同步 DNS 查询，延迟不可控
哪些操作会强制刷新线程权限缓存？
线程缓存并非长期有效，以下任意行为都会导致当前连接的权限缓存失效并重建，带来额外查询和锁竞争：
- 执行
SET ROLE（尤其在 MySQL 8.0+ 动态权限体系下路径更长） - 用户密码过期（
password_expired='Y'）或账户被锁（account_locked='Y'） - 连接池中复用连接后动态切换用户（如
SELECT USER();后再SET @user = 'xxx';）——这会触发上下文重建，而非复用已有缓存 - 修改用户属性（如
ALTER USER ... PASSWORD EXPIRE）后，已存在连接在下次权限检查时才会刷新
批量授权与 GRANT 执行时机怎么影响元数据锁？
GRANT 和 REVOKE 不是纯内存操作，它们会更新 mysql.db、mysql.tables_priv 等系统表，并触发权限缓存全局刷新。若此时有大量活跃连接正在做权限判断，就可能卡在 Waiting for table metadata lock。
- 合并授权：用一条语句完成多权限授予，例如
GRANT SELECT, INSERT, UPDATE ON db.* TO 'u'@'%';，避免拆成三条GRANT SELECT、GRANT INSERT… - 避开高峰执行：权限变更尽量安排在低峰期；若必须在线操作，可先在从库运行
SHOW GRANTS FOR 'u'@'%';验证语法和效果 - 不要手动
FLUSH PRIVILEGES：正常GRANT后权限已生效；仅当你绕过语法直接INSERT INTO mysql.user（严禁生产环境这么做）才需要它
高频账号为什么不该用角色（ROLE）？
MySQL 8.0+ 的角色机制虽灵活，但每个 SET ROLE 都会清空当前线程缓存并重新计算有效权限集，路径比静态权限长 2–3 倍。对每秒数百次连接的 API 账号，频繁激活角色等于主动引入瓶颈。
- 高频账号（如应用连接池使用的
app_rw）应直接授予所需权限，不依赖CREATE ROLE+SET ROLE - 按业务域拆分账号：比如
report_ro@'10.0.1.%'、order_rw@'10.0.2.%'，限制主机范围可减少权限匹配遍历量 - 避免给高频账号设
max_questions等语句级限制：这类计数器需每次执行前校验，增加权限路径负担
真正容易被忽略的是：权限优化不是孤立动作，它和连接池行为、DNS 配置、系统表引擎、甚至账号命名规范都咬合在一起。少一次 SET ROLE、少一个没关的 skip_name_resolve、少一条分散的 GRANT，在万级 QPS 下可能就是几百毫秒的响应差异。
