mysql中revoke后权限未实时生效是因会话权限仅在连接建立时加载，需断开重连或刷新连接池；撤销失败常因权限范围不匹配、残留细粒度权限或用户主机名不一致，须严格比对show grants结果并清理mysql.columns_priv等系统表。
撤销后连接仍有效，权限没刷新
REVOKE 执行成功只改了系统表，不踢掉已有连接。用户当前会话还带着旧权限快照，SELECT、INSERT 照常跑。这不是命令失效，是 MySQL 的会话权限加载机制决定的——权限只在连接建立时读一次。
- 必须让应用断开重连，或重启连接池（如 HikariCP 的
close()+refresh()） -
FLUSH PRIVILEGES在 MySQL 8.0+ 不影响会话权限，它只刷新内存 ACL 缓存，对已存在的连接无感 - Navicat / DBeaver 等 GUI 工具常复用连接，删掉连接配置再新建一个，才能验证真实效果
权限范围没对齐，撤销语句写错了
MySQL 的 REVOKE 不支持模糊匹配或自动推导。你撤的是 app_log.*，但当初授权可能是 app_log.t1 或 app_log.%（注意：后者非法），或者主机名写成了 '%' 而实际是 '10.0.2.%' —— 这些都会导致命令“成功执行却没撤掉任何权限”。
- 先查原始授权：
SHOW GRANTS FOR 'user'@'host'，逐字比对ON后面的部分 - 数据库名、表名、主机名、权限名（如
SELECT大小写敏感）全部要严格一致 - 别用
REVOKE ALL PRIVILEGES ON *.*去碰单个库，它会误清系统库权限，比如mysql或performance_schema
残留权限藏在细粒度表里
你以为撤干净了？mysql.db 表空了，不代表真没了。列级权限存在 mysql.columns_priv，表级单独授过的权限在 mysql.tables_priv，角色继承的权限在 mysql.role_edges。这些都不会被 ON db_name.* 撤掉。
- 查列级残留：
SELECT * FROM mysql.columns_priv WHERE User = 'user' AND Host = 'host' AND Db = 'db_name' - 查角色继承：
SELECT * FROM mysql.role_edges WHERE TO_USER = 'user' AND TO_HOST = 'host' - 查代理权限：
SELECT * FROM mysql.proxies_priv WHERE User = 'user' AND Host = 'host' - 要彻底清理，得挨个
REVOKE或直接DELETE对应系统表记录（操作前务必备份）
用户其实根本没被 revoke 到
常见陷阱：账号不存在、主机名不匹配、甚至压根不是你认为的那个用户。比如 'appuser'@'192.168.1.%' 和 'appuser'@'%' 是两个独立账号；又或者你连的是 localhost，但授权对象是 'appuser'@'127.0.0.1' —— 因为 MySQL 内部把 localhost 当作 socket 连接，不走 TCP，匹配规则不同。
- 确认当前会话身份：
SELECT USER(), CURRENT_USER();，前者是“你怎么登录的”，后者是“MySQL 认你是谁” - 查账号是否存在：
SELECT User, Host FROM mysql.user WHERE User = 'user';，看 Host 列是否和你写的完全一致 - 空用户（
''@'%'）或匿名用户也可能干扰判断，它们常被忽略但能实际登录
真正生效的权限变更，永远依赖三件事：语句写对、连接断开、残留路径扫清。少一个，就等于没撤。
