GRANT OPTION权限不能随便开启，因其允许持权者将自身权限转授他人或创建账号赋权，一旦被攻破或误操作会导致权限体系失控；MySQL 8.0+中角色若拥有该权限风险同样放大。
GRANT OPTION权限为什么不能随便开
GRANT OPTION不是普通权限，它是“发权限的权限”——拥有它的人可以把自己有的任何权限再转授给其他人，甚至创建新账号并赋权。一旦开发人员账号被攻破或误操作，整个实例的权限体系就可能失控。MySQL 8.0+ 中角色虽可封装权限，但若角色本身被赋予 GRANT OPTION，风险同样放大。
如何快速定位已开启GRANT OPTION的账号
别等出事才查。直接执行这条语句，能立刻揪出所有带 Grant_priv 的用户：
SELECT User, Host, Grant_priv FROM mysql.user WHERE Grant_priv = 'Y';
重点检查返回结果中 Host 是 % 或宽泛网段（如 10.%）的账号——这类账号极可能被滥用。对每个命中账号，再执行：
SHOW GRANTS FOR 'dev_user'@'%';
看输出里是否含 WITH GRANT OPTION。只要没明确需要“代授权限”，一律删掉。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
创建开发账号时彻底禁用GRANT OPTION
新建账号时，GRANT 语句里绝不能出现 WITH GRANT OPTION。哪怕只是临时测试，也别加。正确做法是：
- 先用
CREATE USER创建账号，不附带任何权限 - 再用
GRANT显式指定所需最小权限，例如SELECT, INSERT, UPDATE ON app_db.orders - 全程避开
ALL PRIVILEGES和ON *.*，更不能加WITH GRANT OPTION - 如果团队真有“授权代理”需求，应单独建一个 DBA 管理账号（如
dba_admin@localhost），且仅限本地登录
回收已有账号的GRANT OPTION权限
已有账号开了 Grant_priv，不能只删 WITH GRANT OPTION，必须显式回收全局权限位：
REVOKE GRANT OPTION ON *.* FROM 'dev_user'@'10.0.0.%';
注意两点：
- 回收后无需执行
FLUSH PRIVILEGES（MySQL 5.7.6+ 已自动生效） - 如果该账号还通过角色继承了权限，得先查清角色来源：
SELECT * FROM mysql.role_edges WHERE TO_HOST = 'dev_user'@'10.0.0.%';，再从角色层面回收 - 回收完务必验证：用该账号执行
GRANT SELECT ON test.t TO 'test2'@'localhost';，应报错ERROR 1045 (28000): Access denied
真正难防的不是不会开权限，而是忘了关。生产环境里，Grant_priv = 'Y' 的账号必须出现在每日巡检清单里——它不像密码过期那样有告警，全靠人盯。
