revoke grant option必须显式声明，不能混在all privileges中；需严格匹配原授权的user@host、对象范围及大小写，撤销后须用新连接验证，且角色继承的grant option需先撤角色。
REVOKE GRANT OPTION必须显式声明，不能混在ALL PRIVILEGES里
执行 REVOKE ALL PRIVILEGES ON *.* FROM 'u'@'h' 不会动 GRANT OPTION——它被 MySQL 视为独立权限，哪怕你当初是用 GRANT ... WITH GRANT OPTION 一起授的。漏掉这一步，用户仍能给自己或别人再授权，等于留了后门。
正确写法必须带 GRANT OPTION 关键字，并且范围要和原授权完全一致：
- 如果原授权是
GRANT SELECT ON app.* TO 'dev'@'10.0.1.%' WITH GRANT OPTION，那就得写REVOKE GRANT OPTION ON app.* FROM 'dev'@'10.0.1.%' - 如果是全局授权
GRANT ALL PRIVILEGES ON *.* TO 'admin'@'%' WITH GRANT OPTION，对应撤销就是REVOKE GRANT OPTION ON *.* FROM 'admin'@'%' - 想一步清空权限+转授权？用
REVOKE ALL PRIVILEGES, GRANT OPTION ON *.* FROM 'admin'@'%'（注意逗号分隔，不是AND）
主机名、数据库名、大小写三者任一不匹配，REVOKE就静默失败
MySQL 不报错也不提示“没撤成”，只返回 Query OK，但权限还在。常见踩坑点：
-
'dev'@'10.0.1.%'写成'dev'@'%'：这是另一个账号，原账号的 GRANT OPTION 毫发无损 -
ON app.*写成ON app_log.*或ON *.*：范围不一致，命令无效 -
GRANT OPTION写成grant option（小写）：MySQL 权限名大小写敏感，直接报错ERROR 1064 - 库名含横线或特殊字符但没加反引号：
REVOKE GRANT OPTION ON `my-db`.* FROM 'u'@'h'，漏掉反引号会语法错误
撤销后旧连接仍保留GRANT OPTION能力
执行成功只是更新了权限表，已建立的连接（尤其是应用连接池里的长连接）仍带着旧权限快照。这意味着：
- 你刚跑完
REVOKE GRANT OPTION ON *.* FROM 'u'@'h'，立刻用同一个连接执行GRANT SELECT ON test.t1 TO 'x'@'y'可能 still work - 验证是否真生效，必须用新连接测试：
mysql -u u -h db-host -p -e "GRANT SELECT ON test.t1 TO 'x'@'y'"，预期应报ERROR 1045 - 生产环境需滚动重启应用，或等连接超时自然淘汰；MySQL 8.0+ 可在会话内先执行
SET ROLE NONE（若启用了角色），但对直接授予的 GRANT OPTION 无效
查不到 GRANT OPTION 就别急着 revoke
不是所有用户都有 GRANT OPTION，盲目执行可能浪费时间，还掩盖真实问题。先确认它是否存在：
- 查当前用户显式权限：
SELECT Grant_priv FROM mysql.user WHERE User='u' AND Host='h'（全局级） - 查库级 GRANT OPTION：
SELECT Grant_priv FROM mysql.db WHERE User='u' AND Host='h' AND Db='app' - 用
SHOW GRANTS FOR 'u'@'h'看输出里有没有WITH GRANT OPTION字样——注意：这个命令不显示通过角色继承的 GRANT OPTION，得额外查mysql.role_edges和对应角色的权限
真正麻烦的是角色链：比如用户被赋予了 db_admin 角色，而该角色本身有 GRANT OPTION ON app.*。这时 REVOKE GRANT OPTION ON app.* FROM 'u'@'h' 没用，得先 REVOKE 'db_admin' FROM 'u'@'h'，再检查角色定义本身是否需要调整。
