最直接可靠的判断方式是查看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 字样。
- 如果有类似
GRANT SELECT ON `app`.* TO 'dev'@'%' WITH GRANT OPTION，说明该用户对app库有授予权，但仅限于SELECT - 如果有
GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION，说明具备全局授予权 - 如果输出里完全没出现
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”，不包含角色继承来的权限。
常见误判场景：
- 用户被赋予了带
GRANT OPTION的角色，但没执行SET ROLE 'admin'激活，Grant_priv仍为'N'，而实际权限已生效 - 用户只有库级
GRANT OPTION（如GRANT SELECT ON db1.* TO ... WITH GRANT OPTION），mysql.user.Grant_priv仍是'N'，因为这不是全局权限 - 手动 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。
验证步骤：
- 运行
SHOW GRANTS FOR CURRENT_USER()，看结果里有没有WITH GRANT OPTION - 如果没有，补权限：
GRANT ALL PRIVILEGES ON *.* TO CURRENT_USER() WITH GRANT OPTION - 立即执行
FLUSH PRIVILEGES（MySQL 8.0.29+ 通常自动生效，但加了更稳） - 再试一次
GRANT—— 注意：8.0+ 不允许在GRANT语句里写IDENTIFIED BY，必须先CREATE USER或ALTER USER
容易被忽略的 host 匹配细节
SHOW GRANTS FOR 'api'@'%' 和 SHOW GRANTS FOR 'api'@'localhost' 是两个完全不同的查询，哪怕用户是同一个名字，只要 @'host' 不一致，就会报 ERROR 1141。
排查时务必：
- 先用
SELECT User, Host FROM mysql.user WHERE User = 'api';查出完整注册记录 - 复制粘贴整行
User@Host字符串到SHOW GRANTS FOR，别手输、别改%、别加空格 - 注意
'localhost'和'127.0.0.1'在 MySQL 内部是不同 host，权限不互通
真正决定你能给谁授权的，从来不是用户名，而是那一串精确到字符的 'user'@'host' 组合。漏掉一个单引号、错一位通配符，权限就查不到、授不了。
