MySQL权限撤销需严格匹配GRANT粒度与用户标识，不可自动推断；全局权限仅能在.撤销；ALL PRIVILEGES不含GRANT OPTION，须显式单独撤销；REVOKE后应验证并重连生效。
REVOKE 语句必须严格匹配 GRANT 时的粒度和用户标识
撤销权限不是“删掉所有”，而是“精准撤回”——MySQL 不会自动推断你原本想撤哪一层。比如当初用 GRANT SELECT ON sales.orders TO 'report'@'192.168.1.%' 授了某张表的查权，那撤的时候也得写 REVOKE SELECT ON sales.orders FROM 'report'@'192.168.1.%'；若错写成 REVOKE SELECT ON sales.*，就多撤了整个库其他表的权限；写成 REVOKE SELECT ON *.*，更会波及所有数据库。
-
'report'@'192.168.1.%'和'report'@'localhost'是两个完全不同的用户，主机名不一致会导致 “Unknown user” 错误 - 全局权限（如
SUPER、RELOAD、GRANT OPTION）只能在*.*上撤销，写成db.*会报语法错误 - 如果用户是通过角色（role）获得权限，应优先用
REVOKE role_name FROM 'user'@'host'，而非逐条撤底层权限
ALL PRIVILEGES 不含 GRANT OPTION，必须显式单独撤销
这是生产环境最常被忽略的高危疏漏。即使你执行了 REVOKE ALL PRIVILEGES ON *.* FROM 'admin'@'%'，只要没加 GRANT OPTION，该用户仍能给其他人授权——等于留了一把后门钥匙。
- 正确做法是：先撤权限，再单独撤转授权：
REVOKE GRANT OPTION ON *.* FROM 'admin'@'%' - 想一步清空所有（含转授权）？用：
REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'admin'@'%' -
USAGE是空权限，所有用户默认都有，撤销它会被 MySQL 忽略，无意义
撤销后权限不立即生效，但 FLUSH PRIVILEGES 并非总要执行
MySQL 8.0+ 在正常使用 REVOKE 时会自动刷新权限缓存，FLUSH PRIVILEGES 实际上只在直接修改 mysql.user 等系统表后才必需。但运维中为求稳妥，多数人仍会执行它——问题在于，它不是“让撤销生效”的开关，而是“强制重载整张权限表”。
- 执行
REVOKE后，建议立刻用SHOW GRANTS FOR 'user'@'host'验证输出是否已剔除目标权限 - 如果客户端连接未断开，旧连接仍持有原权限，需重新登录才能生效
- 在高并发或权限变更频繁的实例中，
FLUSH PRIVILEGES可能引发短暂锁表，应避开业务高峰
回收前务必确认用户是否存在且权限真实存在
REVOKE 命令本身不校验目标用户是否存在，也不检查该用户是否真有你要撤的权限——它只是“尽力撤”，成功返回 Query OK，失败也往往静默忽略（除非权限系统损坏）。这意味着，你以为撤掉了，其实可能根本没作用。
- 先查当前状态：
SELECT User, Host, Select_priv, Insert_priv FROM mysql.user WHERE User = 'xxx' AND Host = 'yyy' - 再看细粒度权限：
SELECT * FROM mysql.db WHERE User = 'xxx' AND Host = 'yyy'（查库级）、SELECT * FROM mysql.tables_priv WHERE User = 'xxx'（查表级） - MySQL 8.0+ 支持
REVOKE IF EXISTS ...，可避免因权限不存在导致的报错，但不会解决“误撤其他同名用户”的问题
权限撤销真正难的不是语法，而是搞清“谁在什么范围下有什么权限”。一次误操作可能让监控脚本失效、报表中断，甚至留下越权入口。动手前花两分钟查清楚 mysql.user、mysql.db 和 SHOW GRANTS 的输出，比事后排查快十倍。
