<p>phpMyAdmin权限界面不显示GRANT OPTION勾选框,因其属授权能力而非普通权限,必须通过SQL显式授予:GRANT SELECT ON myapp.* TO 'appuser'@'localhost' WITH GRANT OPTION;库名需反引号包裹,主机名须精确匹配,且WITH GRANT OPTION必须依附实际权限、不可单独使用。</p>
phpmyadmin 的权限界面不显示 grant option 勾选框,必须用 sql 显式授予,否则用户执行 grant 语句时会报错 #1045 - access denied。
这不是 UI 缺失,而是设计使然:GRANT OPTION 不是普通权限,不能和 SELECT、INSERT 等并列勾选。phpMyAdmin 的图形化权限页只处理“数据操作类权限”,而 GRANT OPTION 属于“授权能力”,MySQL 要求它必须随具体权限一起显式声明,且只能通过 SQL 授予。
常见错误现象:
GRANT SELECT ON db.* TO 'other'@'%' 就报错必须在 GRANT 语句中同时指定目标权限(如 SELECT)和 WITH GRANT OPTION,缺一不可。
示例(让 appuser 能把 myapp 库的读权限授给他人):
立即学习“PHP免费学习笔记(深入)”;
GRANT SELECT ON `myapp`.* TO 'appuser'@'localhost' WITH GRANT OPTION;
关键点:
`myapp`,防止库名含短横线或关键字时报错'localhost' 就不能用 '%' 替代,MySQL 认证逻辑中二者完全独立WITH GRANT OPTION 必须写在语句末尾,不能放在括号内、不能拆成多行、不能单独写成 GRANT GRANT OPTION ON ...
GRANT USAGE 或空权限列表——GRANT OPTION 必须依附于至少一个实际数据权限即使 SQL 执行成功,用户仍可能无法转授,原因往往卡在底层细节:
'appuser'@'localhost')与授权语句中的一致myapp 必须真实存在;MySQL 不允许对不存在的库授予表级或库级权限ALL PRIVILEGES ON *.*),新授的窄权限不会自动覆盖,需先 REVOKE 再 GRANT,否则可能报错 #1221 - Incorrect usage of GRANT and NO PRIVILEGES
SHOW GRANTS; 确认输出里包含 WITH GRANT OPTION —— 这是最直接的验证方式绝大多数情况下不需要。MySQL 5.7+ 和 8.0 默认在执行 GRANT 后自动重载权限表。FLUSH PRIVILEGES 只在一种场景下必须加:你曾手动 UPDATE mysql.user 修改过 Grant_priv 字段(比如直接改表赋权)。正常走 GRANT ... WITH GRANT OPTION 流程,就别画蛇添足。
容易被忽略的是:权限生效后,用户必须用新连接登录才能使用转授权限——旧连接会沿用缓存的权限快照,哪怕你刚授完权。