revoke执行后权限在服务端立即生效，但已存在会话不自动刷新，需重连或kill连接才能使变更对当前用户立即生效。
REVOKE 不影响已存在的连接
MySQL 的 REVOKE 语句只修改权限表（mysql.user、mysql.db 等），不会主动中断或刷新当前活跃连接的权限上下文。每个连接在建立时会缓存一份权限快照，后续所有操作都基于这份快照判断，直到连接断开或显式重载。
如何让权限变更立即生效
有两种可靠方式让新权限规则对现有连接起效：
-
FLUSH PRIVILEGES本身不重置已有连接权限 —— 这是常见误解；它只重新加载权限表到内存，但不触达已建立连接 - 必须让连接「重新认证」：最直接的是断开重连（客户端主动重连或服务端 kill 连接）
- 或者在连接内执行
SET ROLE DEFAULT（仅限 MySQL 8.0+ 启用角色机制且用户使用了角色）—— 但这不回退REVOKE的全局/库级权限，仅影响当前激活的角色
KILL 连接后权限才真正更新
如果你需要立刻阻断某用户对刚被 REVOKE 的权限的访问，唯一稳妥做法是主动终止其活跃连接：
SELECT CONCAT('KILL ', id, ';') FROM information_schema.processlist WHERE user = 'xxx';
然后执行生成的 KILL 语句。下次该用户重连时，会读取更新后的权限表，自然受限。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
注意：KILL 不会丢数据（除非正在执行写操作且未提交），但会中断当前语句并返回 MySQL server has gone away 类错误给客户端。
为什么设计成这样？性能和一致性考虑
MySQL 避免在每次权限检查时都查表或加锁，所以选择「连接初始化时快照权限」。这带来两个实际影响：
- 高并发下频繁
GRANT/REVOKE不会造成连接层锁争用 - 但运维侧容易误判：看到
REVOKE成功就以为权限已失效，其实老连接还能继续操作 - 尤其在审计或应急响应场景中，这个延迟可能构成风险盲区
真正要确认权限是否落地，不能只看 SHOW GRANTS FOR 'u'@'h'，还得查 information_schema.processlist 看是否有旧连接残留。
