Navicat改权限后应用连不上，因连接池复用旧连接且权限仅在建连时校验；需清空连接池或重建连接，并确认CURRENT_USER()匹配授权账号及权限粒度是否支持热生效。
Navicat里改完权限，应用连不上？先看连接是不是复用的旧会话
Navicat 本身执行 GRANT 是没问题的，但应用端（比如 Java 应用、Python 脚本）几乎从不重连——它用的是连接池里缓存的连接。MySQL 权限只在连接建立时校验一次，已存在的连接不会感知后续 GRANT 变更。
- 应用重启 ≠ 连接重建：很多框架（如 Spring Boot + HikariCP）默认保持连接池存活，即使你重启了应用进程，池中旧连接仍持有旧权限快照
- 必须清空连接池或设置
connectionInitSql触发重连（例如SELECT 1不够，得断开重连） - Navicat 自己新建查询窗口是新连接，所以你在 Navicat 里能立刻验证权限；但应用走的是另一条连接路径，完全不受影响
Navicat 显示“授权成功”，但应用报 Access denied？查 CURRENT_USER() 而不是 USER()
Navicat 默认可能用 root 或其他高权限账号执行 GRANT，但它授权的对象（比如 'appuser'@'%' ）和应用实际连接时匹配到的账号，常常不是同一个。
- 在应用连接的数据库里执行
SELECT USER(), CURRENT_USER();：前者是你“声称”的用户，后者才是 MySQL 实际匹配到的(user, host)组合 - 常见错配：
'appuser'@'localhost'（Navicat 本地授权） vs'appuser'@'10.0.2.15'（Docker 容器内应用连接），host 不一致就完全不生效 - Navicat 的“用户与权限”界面有时会隐藏 host 精确值（比如把
'appuser'@'192.168.1.%'显示成appuser），容易误判
Navicat 改权限后，应用仍提示权限不足？确认授的是哪一级权限
不是所有权限都“改完就能用”。MySQL 对不同粒度权限的生效时机做了硬性区分，Navicat 无法绕过这个机制。
-
GRANT SELECT ON mydb.* TO 'u'@'h';（数据库级）：应用需先执行USE mydb;才触发权限加载，单纯连上就查表会失败 -
GRANT SELECT ON mydb.mytable TO 'u'@'h';（表级）：下一条SELECT * FROM mytable;就生效，当前连接内可用 -
GRANT ALL PRIVILEGES ON *.* TO 'u'@'h';（全局级）：必须应用断开所有连接、重建连接池，否则永远无效
Navicat 里点了“刷新权限”，结果更糟？别信那个按钮
Navicat 的“刷新权限”按钮本质是执行 FLUSH PRIVILEGES;，而这是个误导性操作——对标准 GRANT 完全多余，还可能掩盖真实问题。
-
GRANT语句本身已自动刷新内存缓存，FLUSH PRIVILEGES加了也不多一分效果 - 如果 Navicat 没执行成功
GRANT（比如语法错、数据库名不存在、用户根本不存在），点“刷新”只会让你更坚信“权限改了但没用” - 某些托管环境（如阿里云 RDS）直接禁用
FLUSH PRIVILEGES，点一下就报错ERROR 1227 (42501)，反而干扰排查
真正卡住人的，从来不是 Navicat 点得够不够快，而是应用连接池有没有真正切断旧连接、CURRENT_USER() 匹配到的账号是不是你授权的那个、以及你授的权限粒度是否支持当前连接内热生效。这些细节，Navicat 界面一眼看不到。
