REVOKE 不是“删用户”，只是精准摘掉权限，用错格式或忽略主机名会导致撤销失败甚至误操作。
REVOKE 基本语法和必须写对的三要素
MySQL 中撤销权限不是“删掉某个动作”，而是按
权限类型 + 作用范围 + 用户标识三者严格匹配来执行。缺一不可，尤其容易漏掉的是主机名部分。
权限类型：如
SELECT、
INSERT、
ALL PRIVILEGES（注意不是
ALL，虽然某些版本兼容，但标准写法带
PRIVILEGES）
ON后必须是完整对象路径：
*.*（全局）、
dbname.*（库级）、
dbname.tbl（表级）——
ON *或
ON testdb是非法写法，会报错
FROM 'user'@'host'必须和当初
GRANT时完全一致：比如
'api'@'10.0.0.%'和
'api'@'%'是两个不同用户，不能混用；单引号必须保留，双引号或不加引号都可能出错
REVOKE INSERT, UPDATE ON applog.* FROM 'logger'@'192.168.5.%'; REVOKE ALL PRIVILEGES, GRANT OPTION ON *.* FROM 'temp_dev'@'%';
撤销后权限为什么“还在用”？会话缓存是关键
执行
REVOKE后，新连接立刻生效，但当前已建立的连接仍沿用旧权限缓存，直到断开重连。这不是 bug，是 MySQL 的会话权限加载机制决定的。 常见现象：撤销了
DELETE权限，用户在原终端还能删数据 → 让他退出 MySQL 客户端再重连即可
FLUSH PRIVILEGES在
REVOKE后不是必须的（它只对直接改
mysql.user表有效），但执行也无害，可作为保险步骤 若需强制终止活跃会话，得配合
KILL CONNECTION [id]，而不是靠
REVOKE立即阻断
高频误操作与安全避坑点
权限回收比授权更容易引发意外，因为“撤销不彻底”或“撤销过头”都难回滚（除非有备份权限快照）。
别指望REVOKE ALL PRIVILEGES自动带走
GRANT OPTION—— 它俩独立存在，必须显式写上：
REVOKE ALL PRIVILEGES, GRANT OPTION撤销
FILE、
SUPER、
SHUTDOWN这类管理权限时，必须用
ON *.*，其他作用域无效 用
%主机通配符要小心：撤销
'dev'@'%'可能影响所有远程开发账号，建议先
SHOW GRANTS FOR 'dev'@'%'确认范围
REVOKE对不存在的权限会报错（
ERROR 1141 (42000): There is no such grant defined for user ...），不是静默忽略，所以务必先查再撤
SHOW GRANTS FOR 'reporter'@'172.16.0.%'; REVOKE SELECT ON finance.* FROM 'reporter'@'172.16.0.%';
撤销后怎么确认真的没了？
别信感觉，用
SHOW GRANTS看输出结果最可靠。注意它返回的是该用户当前**所有有效权限合并后的视图**，包括从不同
GRANT语句累加的结果。 如果看到
GRANT USAGE ON *.* TO ...是正常现象 —— 这代表用户账户还存在，但没被授予任何实际权限 若输出里仍有
SELECT或其他不该有的权限，说明撤销语句没命中目标用户，或权限是在另一条
GRANT中授予的（比如先授了
testdb.*，又授了
testdb.users，只撤后者不会影响前者） 跨库权限要注意：撤销
ON myapp.*不会影响
myapp_log.*，哪怕库名相似
真正麻烦的不是语法写不对，而是搞不清「哪个用户在哪台机器上到底被授了哪些权限」——生产环境建议定期导出
SELECT User, Host, Select_priv, Insert_priv, ... FROM mysql.user;做基线比对。
