MySQL里用GRANT OPTION授权后，被授权用户真的能转授权限吗？

在MySQL的权限体系里，GRANT OPTION是一个容易被忽略但影响深远的选项。它决定了被授权的用户能否将自己拥有的权限再授予其他账户。很多团队在做数据库运维时，只关注用户能不能连库、能不能读写，却没注意转授权带来的横向扩散风险。下面先放一张示意图帮助理解权限传递关系。

GRANT OPTION是什么

GRANT OPTION是MySQL授权语句中的一个可选子句。当你执行GRANT命令把一个或一组权限赋予某个用户时，如果同时写了WITH GRANT OPTION，那么这个用户就获得了把自己拥有的同名权限转授给其他用户的资格。注意它并不是一种独立权限，而是附着在已有权限上的能力标记。

从底层存储看，MySQL会把这种能力记录在后端的权限表里面。比如全局权限写在mysql.user表的Grant_priv列，库级权限写在mysql.db表的Grant_priv列。当Grant_priv值为Y时，代表该范围下的权限可转授；为N时则不行。这意味着即使一个用户有SELECT权限，只要Grant_priv是N，他就不能执行GRANT SELECT ON db.* TO 'other'@'host'。

如何正确使用GRANT OPTION

下面是一个典型的授权示例，把一个库的读写权限赋予用户app_user，并允许他转授：

-- 创建用户
CREATE USER 'app_user'@'192.168.0.1' IDENTIFIED BY 'strong_pass';

-- 赋予库级权限并允许转授
GRANT SELECT, INSERT, UPDATE, DELETE
ON shop_db.*
TO 'app_user'@'192.168.0.1'
WITH GRANT OPTION;

执行后，app_user不仅能操作shop_db，还能把同样范围的SELECT等权限发给别人。我们切换到该用户执行转授语句验证：

-- 以app_user身份登录后执行
GRANT SELECT ON shop_db.* TO 'read_only'@'192.168.0.1';

如果当初没有写WITH GRANT OPTION，上面这句就会报错：Access denied for user 'app_user'@'192.168.0.1' to database 'shop_db'。这就是有无该选项最直接的差异。需要提醒的是，转授者只能授予自己已被赋予的权限，不能扩大范围，比如他不能把DROP权限给別人，除非他自己也被赋予了DROP且带GRANT OPTION。

权限委托的风险与控制

权限委托在大型团队能减少DBA负担，让模块负责人自行管理子账号。但失控的GRANT OPTION会造成权限雪球式膨胀，脱离统一管控。曾经有案例，一个临时查询账号被误授WITH GRANT OPTION，结果该账号创建了多个高权限子账号，留下安全隐患。

回收委托权不能用REVOKE某个叫GRANT OPTION的权限，而要通过重新授权不带该选项，或直接收回原权限。示例如下：

-- 收回app_user的转授权能力（先收回原权限再重赋）
REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'app_user'@'192.168.0.1';
GRANT SELECT, INSERT, UPDATE, DELETE ON shop_db.* TO 'app_user'@'192.168.0.1';

另外，定期审计mysql.user和mysql.db中Grant_priv为Y的记录，可以快速定位哪些账户具备转授能力。对于生产环境，建议默认不开启GRANT OPTION，仅在明确需要自助式权限管理时，对特定账户做最小范围授权。

常见误区澄清

有人以为SUPER权限或ALL PRIVILEGES会自动包含转授权，其实ALL PRIVILEGES本身不含GRANT OPTION，必须显式加WITH GRANT OPTION。还有人混淆了GRANT OPTION与PROXY权限，后者是代理用户身份，和权限委托不是一回事。在写授权脚本时，应当把是否需要转授作为独立开关来审视，而不是默认带上。

通过理解GRANT OPTION的存储机制、授权语法与回收方式，你能更安全地设计MySQL账户体系，既保留灵活度也守住权限边界。

MySQLGRANT_OPTION权限委托修改时间：2026-08-06 12:48:26