REVOKE 命令能撤销 GRANT 权限，但需严格匹配授权范围、层级及是否含 GRANT OPTION；撤销 ALL PRIVILEGES 不影响后续单独授予的权限；角色权限需显式撤销；MySQL 5.7 与 8.0+ 在列权限和动态权限处理上存在差异。
REVOKE 命令到底能不能撤回 GRANT 的权限
能，但不是所有权限都能随时无损撤销——关键看是否涉及 GRANT OPTION 和权限层级。MySQL 的权限模型是分层的（全局、库、表、列），REVOKE 必须严格匹配当初 GRANT 时的范围和类型，否则会报错或无效。
常见错误现象：ERROR 1141 (42000): There is no such grant defined for user 'u1' on host '%'，本质是权限范围不一致（比如当初在 db1.* 上授权，却试图从 *.* 撤销）。
- 必须用和
GRANT完全相同的对象范围：如果授权是ON db1.t1，撤销也得写ON db1.t1，不能简写为ON db1.* - 如果原授权带
WITH GRANT OPTION，撤销时要显式加上GRANT OPTION FOR才能收回转授权能力 - 撤销
ALL PRIVILEGES不等于撤销所有权限——它只撤回当时用ALL授予的那批，后续单独加的权限（如后来GRANT SELECT ON db2.*）不受影响
撤销用户对某个数据库的全部权限
最常踩的坑是误以为 DROP USER 或 DELETE FROM mysql.user 是安全做法——这会直接删账号，且可能残留 mysql.db 或 mysql.tables_priv 中的权限记录，导致权限残留或不一致。
正确做法是逐层回收：
- 先撤销具体对象权限：
REVOKE ALL PRIVILEGES ON `myapp`.* FROM 'appuser'@'%'; - 再撤销该用户已有的全局级权限（如有）：
REVOKE ALL PRIVILEGES ON *.* FROM 'appuser'@'%'; - 最后刷新：
FLUSH PRIVILEGES;（注意：仅在修改系统表后才必须；用REVOKE命令操作通常自动生效，但部分旧版本 MySQL 5.7 及以下建议执行）
不推荐用 DELETE FROM mysql.db WHERE User='appuser' 等直接改系统表的方式——容易破坏权限缓存一致性，且 MySQL 8.0+ 的角色权限模型会让这类操作失效。
撤销权限后为什么 SELECT 还能执行
权限检查是叠加生效的，不是“覆盖”逻辑。一个用户可能通过多个来源获得同一权限：比如 appuser 在 myapp.* 上被授予 SELECT，同时又属于角色 reader_role，而该角色也拥有 SELECT 权限。此时只撤销直接授予的权限，角色带来的权限依然有效。
- 查清权限来源：
SHOW GRANTS FOR 'appuser'@'%';和SHOW GRANTS FOR 'appuser'@'%' USING 'reader_role'; - 若用角色，需同时撤销角色：
REVOKE 'reader_role' FROM 'appuser'@'%'; - MySQL 8.0+ 中，
REVOKE不会自动级联撤销角色内嵌权限，必须显式处理角色绑定关系
REVOKE 在不同 MySQL 版本的行为差异
MySQL 5.7 和 8.0 对 REVOKE 的语义处理有实质性区别，尤其涉及列权限和动态权限。
- MySQL 5.7 不支持撤销列级权限（如
REVOKE SELECT(col1) ON t1 FROM u1会报错），只能整表撤销后重新授其他列 - MySQL 8.0+ 支持细粒度列权限撤销，但要求服务器启用
check_proxy_users插件且用户无活跃连接，否则可能提示ERROR 3717 (HY000): Cannot revoke privileges from a user with active connections - 动态权限（如
CONNECTION_ADMIN）在 8.0+ 中必须用REVOKE显式撤销，不能混在ALL PRIVILEGES里一并操作
生产环境执行前，务必确认 MySQL 版本并验证目标权限是否真被移除——最可靠的方式是用该用户连上去实测关键语句，别只信 SHOW GRANTS 输出。
