如何检查MySQL用户是否拥有GRANT OPTION

最直接可靠的判断方式是查看SHOW GRANTS FOR输出中是否含WITH GRANT OPTION；该字样出现在权限语句末尾，表明用户在对应范围具备授予权，而mysql.user表的Grant_priv字段因角色、库级权限或未刷新等原因可能不准。

SHOW GRANTS FOR 输出里有没有 WITH GRANT OPTION

这是最直接、最可靠的判断方式。MySQL 不会把 GRANT OPTION 当成独立权限展示，而是作为已有权限语句的后缀出现。

执行 SHOW GRANTS FOR 'username'@'host'（注意必须写全 @'host'，比如 'admin'@'%' 或 'root'@'localhost'），然后逐行检查输出中是否有 WITH GRANT OPTION 字样。

1. 如果有类似 GRANT SELECT ON `app`.* TO 'dev'@'%' WITH GRANT OPTION，说明该用户对 app 库有授予权，但仅限于 SELECT
2. 如果有 GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION，说明具备全局授予权
3. 如果输出里完全没出现 WITH GRANT OPTION，哪怕权限看起来很全，也意味着不能给别人授权

为什么查 mysql.user 表的 Grant_priv 字段不准

SELECT Grant_priv FROM mysql.user WHERE User='u1' AND Host='%' 返回 'Y'，不代表当前就能执行 GRANT —— 尤其在 MySQL 8.0+ 启用角色后，这个字段只反映“是否被直接授予过全局 GRANT OPTION”，不包含角色继承来的权限。

常见误判场景：

1. 用户被赋予了带 GRANT OPTION 的角色，但没执行 SET ROLE 'admin' 激活，Grant_priv 仍为 'N'，而实际权限已生效
2. 用户只有库级 GRANT OPTION（如 GRANT SELECT ON db1.* TO ... WITH GRANT OPTION），mysql.user.Grant_priv 仍是 'N'，因为这不是全局权限
3. 手动 UPDATE 过 mysql.user 表但忘了 FLUSH PRIVILEGES，字段值和实际权限状态不一致

MySQL 8.0+ 下 GRANT 失败却显示“Access denied”？先确认你是不是真有 GRANT OPTION

即使你是 root 登录，GRANT SELECT ON mydb.* TO 'u1'@'%' 报 ERROR 1045 (28000): Access denied，大概率不是密码或主机名问题，而是当前账号没开 GRANT OPTION。

验证步骤：

1. 运行 SHOW GRANTS FOR CURRENT_USER()，看结果里有没有 WITH GRANT OPTION
2. 如果没有，补权限： GRANT ALL PRIVILEGES ON *.* TO CURRENT_USER() WITH GRANT OPTION
3. 立即执行 FLUSH PRIVILEGES（MySQL 8.0.29+ 通常自动生效，但加了更稳）
4. 再试一次 GRANT —— 注意：8.0+ 不允许在 GRANT 语句里写 IDENTIFIED BY，必须先 CREATE USER 或 ALTER USER

容易被忽略的 host 匹配细节

SHOW GRANTS FOR 'api'@'%' 和 SHOW GRANTS FOR 'api'@'localhost' 是两个完全不同的查询，哪怕用户是同一个名字，只要 @'host' 不一致，就会报 ERROR 1141。

排查时务必：

1. 先用 SELECT User, Host FROM mysql.user WHERE User = 'api'; 查出完整注册记录
2. 复制粘贴整行 User@Host 字符串到 SHOW GRANTS FOR，别手输、别改 %、别加空格
3. 注意 'localhost' 和 '127.0.0.1' 在 MySQL 内部是不同 host，权限不互通

真正决定你能给谁授权的，从来不是用户名，而是那一串精确到字符的 'user'@'host' 组合。漏掉一个单引号、错一位通配符，权限就查不到、授不了。