MySQL的REVOKE操作即时生效，但需用户重连或清空连接池；必须指定完整账号（User@Host）；SHOW GRANTS不显示隐式权限；EXECUTE权限需单独撤销，DEFINER权限不受影响。
revoke 命令执行后权限没立刻失效？
MySQL 的 REVOKE 操作是即时生效的，但前提是用户当前连接未缓存旧权限。常见现象是：你执行了 REVOKE，接着用同一个已存在的连接去测试，发现还能访问被撤掉的表——这不是命令没生效，而是连接还拿着旧的权限快照。
实操建议：
- 执行
REVOKE后，让目标用户断开并重连（或你自己用mysql -u user -p新起一个连接验证） - 如果用的是连接池（如 Java 的 HikariCP、Python 的 SQLAlchemy），需重启应用或清空连接池，否则旧连接持续有效
- 确认是否在错误的数据库上下文中操作：
REVOKE SELECT ON db1.* FROM 'u'@'%'不会影响db2上的同名用户权限
撤销权限时忘记指定 host 或拼错用户名
MySQL 把 'user'@'host' 当作一个完整账号，'admin'@'localhost' 和 'admin'@'%' 是两个独立账号。常见错误是只撤销了其中一个，结果用户换台机器或改用 127.0.0.1 连接就绕过了限制。
实操建议：
- 先查清楚账号全貌：
SELECT User, Host FROM mysql.user WHERE User = 'xxx'; - 撤销时务必写全
Host，比如REVOKE INSERT ON mydb.* FROM 'app'@'10.20.%.%'; - 别依赖模糊匹配——MySQL 不支持
REVOKE ... FROM 'app'@'%'同时覆盖所有 host 变体
revoke 之后 show grants 看不到变化？
SHOW GRANTS FOR 'u'@'h' 显示的是该账号当前被显式授予的权限，不包含隐式继承或全局默认权限。如果你之前只授过 USAGE，又没给过其他权限，REVOKE 后再查可能显示空，但这不代表“没权限”——因为新用户默认有 USAGE（可连库，但啥都干不了），而 USAGE 本身不能被 REVOKE。
实操建议：
- 用
SHOW GRANTS FOR 'u'@'h'验证前，先确认该账号确实曾被授予过你要撤的权限 - 如果想彻底清空权限，得逐条
REVOKE，或直接DROP USER 'u'@'h'再重建（注意：5.7+ 才支持DROP USER自动清理权限） - 别忽略
WITH GRANT OPTION：它控制的是“能否转授”，要单独REVOKE GRANT OPTION ON ...，否则即使撤了 SELECT，用户仍能把自己剩下的权限转给别人
revoke 对存储过程、函数、视图的影响
MySQL 的权限模型里，对存储对象的执行权（EXECUTE）和定义者权限（DEFINER）是分开管理的。直接 REVOKE SELECT ON tbl FROM u 并不会阻止用户调用一个 DEFINER='root'@'localhost' 的存储过程，只要该过程内部有合法的 SELECT，且用户有 EXECUTE 权限。
实操建议：
- 检查对象定义：
SHOW CREATE PROCEDURE proc_name;看DEFINER是谁 - 若想限制执行，必须
REVOKE EXECUTE ON PROCEDURE db.proc_name FROM 'u'@'h'; - 视图同理，但要注意：如果视图基于多张表，而你只撤了一张表的 SELECT，用户仍可能通过视图读到数据（只要视图定义者有权限）
权限回收不是删一行就完事的事，关键在账号粒度、连接状态、对象定义三处容易漏看。尤其当业务用连接池或大量使用 DEFINER 时，光靠 REVOKE 很难真正切断访问路径。
