不生效。MySQL权限变更不影响已建立的活跃会话，权限在认证阶段加载并缓存于会话内存中，仅新连接读取最新配置；FLUSH PRIVILEGES仅刷新服务端内存缓存，无法使当前会话热更新权限。
MySQL权限修改后，当前已连接的会话是否立即生效？
不生效。MySQL权限变更（如 GRANT、REVOKE、直接改 mysql.user 表）**不会影响已建立的活跃会话**，这些会话仍沿用登录时加载的权限快照。
这意味着：你刚给用户加了 DELETE 权限，但该用户当前连接仍无法执行 DELETE；同理，刚回收了权限，当前会话还能继续操作——直到重新连接。
- 权限在用户认证阶段加载，存于会话内存中，后续不轮询权限表
-
FLUSH PRIVILEGES只刷新内存中的权限缓存，对已登录会话无作用 - 只有新连接（包括重连、新客户端连接）才会读取最新权限配置
哪些操作能强制让权限在当前会话中“生效”？
没有直接命令能让当前会话“热更新”权限。唯一可靠方式是**断开并重建连接**。
常见误操作：FLUSH PRIVILEGES 后以为权限立刻可用，结果报错 ERROR 1142 (42000): SELECT command denied —— 这恰恰说明会话没重载权限。
- 应用层：调用
mysql_close()+mysql_connect()（或对应语言的 reconnect） - 命令行：退出
mysql客户端（输入EXIT或\q），再重新登录 - 连接池场景需清空/重启连接池，否则旧连接可能被复用
为什么 mysql.user 表直改后还要 FLUSH PRIVILEGES？
因为 MySQL 服务端不会自动监听系统表变更。手动更新 mysql.user 等权限表后，必须显式执行 FLUSH PRIVILEGES，否则新记录根本不会被加载进内存缓存——也就不可能被任何新会话读到。
- 使用
GRANT/REVOKE语句时，MySQL 自动完成写表 + 刷新，无需手动FLUSH - 跳过
FLUSH PRIVILEGES直接改表 → 新权限对所有新连接都不可见 -
FLUSH PRIVILEGES不影响现有会话，只更新服务端内存缓存供后续连接使用
生产环境权限变更要注意什么？
最容易被忽略的是长连接和连接池行为。例如一个 Java 应用用了 HikariCP，默认连接可能空闲数小时不释放，即使你改了权限并 FLUSH，只要它没重建连接，就永远拿不到新权限。
- 检查应用是否启用了连接复用、最大生命周期（
maxLifetime）、空闲超时（idleTimeout） - 临时紧急授权时，优先用
GRANT而非直改表，避免漏掉FLUSH - 回收高危权限（如
SUPER、FILE）后，应主动通知相关服务重启或重连，不能依赖“过一会儿自动生效”
权限不是配置文件 reload，它是会话级快照——这个前提没意识到，排查就会绕远路。
