REVOKE语句必须严格匹配GRANT的粒度，如REVOKE SELECT ON mydb.users FROM 'u1'@'localhost'；回收所有权限用REVOKE ALL PRIVILEGES, GRANT OPTION ON .；执行后自动刷新权限，无需FLUSH PRIVILEGES。
REVOKE 语句怎么写才有效
MySQL 中收回权限必须用 REVOKE，不能靠删用户或改表绕过。它和 GRANT 是镜像操作，语法结构严格对应——你之前用什么范围、什么权限、什么对象授的权，就得用同样粒度去回收，否则可能看似执行成功，实际没生效。
常见错误是只写权限名不写作用域，比如：REVOKE SELECT FROM 'u1'@'localhost' 会报错，因为缺少 ON db.tbl 部分。
- 必须明确指定数据库和表：如
REVOKE SELECT ON mydb.users FROM 'u1'@'localhost' - 要回收所有权限，用
REVOKE ALL PRIVILEGES, GRANT OPTION ON *.* FROM 'u1'@'localhost' - 回收全局权限（如
PROCESS、RELOAD）必须用ON *.* - 执行后需
FLUSH PRIVILEGES—— 但仅当直接修改mysql系统表时才需要；用REVOKE命令本身则自动刷新，无需再刷
回收权限后用户还能连上吗
能连，只要用户还有 USAGE 权限（创建用户时默认赋予）。这个权限不包含任何操作能力，只允许连接认证。所以即使你 REVOKE ALL，用户仍可登录，但执行任何语句都会报 ERROR 1044 (42000): Access denied for user...。
-
USAGE不可被显式回收，它是“最低权限基线” - 真正断连需用
DROP USER 'u1'@'localhost'或禁用账号（如设空密码 +ACCOUNT LOCK） - 注意：MySQL 8.0+ 的角色（role）权限也遵循同样回收逻辑，
REVOKE role_name FROM user即可解绑
为什么 REVOKE 后 SHOW GRANTS 还显示旧权限
大概率是因为权限缓存未刷新，或你回收的是某个具体库表，但用户在其他库仍有同名权限。MySQL 的权限检查是叠加的：对某张表的 SELECT 权限，可能来自 mydb.*、*.*、甚至某个角色，REVOKE 只清除你指定的那一项。
- 查完整权限视图：运行
SHOW GRANTS FOR 'u1'@'localhost'，确认输出里是否还存在目标权限行 - 检查角色继承：
SELECT * FROM mysql.role_edges WHERE TO_HOST = 'localhost' AND TO_USER = 'u1'; - 跨库影响：如果用户有
GRANT SELECT ON *.*，那么REVOKE SELECT ON mydb.tbl无效——通配符优先级更高，得先收全局再收局部
生产环境回收权限要注意什么
权限回收不是原子操作，尤其涉及多个库表或角色时，容易漏掉分支路径。最稳妥的方式是先导出当前权限快照，再批量回收，最后验证。
- 导出权限：
mysqldump -u root -p --no-data --skip-triggers mysql | grep "GRANT.*'u1'@'localhost'" > grants_before.sql - 避免直接
REVOKE ALL后再补授权——中间窗口期可能引发应用报错 - MySQL 5.7 不支持
REVOKE回收列级权限（如SELECT(col1)），只能整表回收；8.0+ 支持，但语法必须带括号：REVOKE SELECT(col1) ON db.tbl FROM 'u1'@'localhost' - 如果用户有
GRANT OPTION，回收时务必一并去掉，否则他还能自行再授出去
权限模型本身有层级穿透性，一个 REVOKE 命令解决不了嵌套授权或角色链带来的残留权限，得结合 SHOW GRANTS 和系统表交叉核对。
