REVOKE 是精准撤销权限而非删除用户，必须严格匹配权限类型、作用范围和用户标识（含主机名）；撤销后新连接立即生效，但当前会话仍缓存旧权限，需重连或 KILL CONNECTION 才能生效。
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; 做基线比对。
