不能，REVOKE ALL PRIVILEGES仅撤销当前ON子句范围内的显式授权，不处理GRANT OPTION、USAGE连接权、角色绑定及mysql.user表中的全局管理权限，需分层执行REVOKE USAGE、REVOKE ALL PRIVILEGES, GRANT OPTION、解绑角色并重连验证。
不能靠一条 REVOKE ALL PRIVILEGES 就清空用户所有权限。它只撤回显式授予的那部分，对 GRANT OPTION、USAGE 连接权、角色绑定、全局管理权限（如 SUPER、RELOAD）完全无效。
REVOKE ALL PRIVILEGES 只作用于当前 ON 子句范围
这条命令不会跨层级生效。比如你在 myapp.* 上执行了 REVOKE ALL PRIVILEGES ON myapp.* FROM 'u'@'%'，它不会动 mysql.* 或 information_schema.* 上单独授过的权限，也不会影响 *.* 全局权限字段里的内容。
常见错误现象：
-
REVOKE ALL PRIVILEGES ON *.* FROM 'u'@'%'执行后，用户仍能连上、执行SHOW DATABASES、查information_schema—— 因为USAGE权限没被碰，且 MySQL 默认允许访问information_schema； - 用户还能给其他人授权 —— 因为
GRANT OPTION没被显式撤销； - 用户仍有
SUPER或PROCESS权限 —— 这些是mysql.user表字段控制的，REVOKE不处理。
MySQL 8.0 必须分层清理：先收连接权，再清显式授权，最后处理角色
所谓“快速清空”，其实是按粒度逐层执行：
- 先撤销连接权：
REVOKE USAGE ON *.* FROM 'u'@'%'—— 这步让用户彻底无法登录（注意：不是“禁用账号”，而是剥夺最基础的连接能力）； - 再清全局显式权限：
REVOKE ALL PRIVILEGES, GRANT OPTION ON *.* FROM 'u'@'%'； - 逐库清理（如有）：
REVOKE ALL PRIVILEGES, GRANT OPTION ON `db_name`.* FROM 'u'@'%'（数据库名务必用反引号包裹，防关键字冲突）； - 检查角色绑定：
SELECT * FROM mysql.role_edges WHERE TO_USER = 'u' AND TO_HOST = '%'，若有结果，对每个FROM_USER执行REVOKE 'role_name' FROM 'u'@'%'； - 如果确认该角色已无其他用户使用，可后续执行
DROP ROLE 'role_name'彻底删除定义。
撤销后权限不立即对已有连接生效
这是最容易被忽略的生产风险点。已建立的连接（包括应用连接池里的长连接）仍持有旧权限缓存，直到断开重连才会刷新。
所以：
- 别只看
REVOKE返回Query OK就认为完事了； - 必须立刻验证：
SHOW GRANTS FOR 'u'@'%'，确认输出里已无目标权限项； - 若在业务高峰期操作，建议配合
ALTER USER 'u'@'%' ACCOUNT LOCK强制阻断新连接，并通知应用侧主动下线旧连接； -
FLUSH PRIVILEGES在纯REVOKE操作后通常不需要，它只在直接改系统表时才强制必需。
真正决定权限是否“消失”的，从来不是某条命令是否执行成功，而是连接是否重置、角色是否解绑、USAGE 是否被撤——这三者缺一不可。
