MySQL报错3897，系统权限不能授予强制角色，远程帮忙修复中

我正在远程协助一位开发人员处理一个棘手的MySQL数据库权限问题,那天下午，他的消息弹出来，语气有些焦急，说他们在进行用户权限调整时，系统突然抛出了一个之前没怎么见过的错误，代码是3897，完整的错误信息是“ERROR 3897 (HY000): System privilege cannot be granted to a mandatory role.”，这个错误直接导致他们预设的权限变更脚本执行失败，一个关键的应用服务因此无法正常连接到数据库，情况有点紧急。

由于是远程支持,我首先需要他完整地复现一遍导致报错的操作步骤，他告诉我，他们的本意是想加强数据库的安全性，计划创建一个新的角色，比如叫做“app_read_only”，这个角色只拥有对某些业务表的只读权限，他们打算将这个角色授予给一个特定的应用程序用户，app_user”，这听起来是一个非常标准和合理的权限管理流程，问题出在了一个额外的步骤上：他们可能参考了某个旧的脚本或者文档，在创建角色并授予了基本的SELECT对象权限之后，又尝试执行了一条类似GRANT SELECT ON *.* TO 'app_read_only';这样的语句，正是在执行这条语句时，错误3897出现了。

看到这个错误代码和描述,我立刻意识到问题的核心可能出在“强制角色”这个概念上，我让他登录到MySQL服务器，切换到mysql系统数据库，然后查询一下当前有哪些角色被标记为了强制角色，他执行了SELECT * FROM mysql.roles_mysql;（注：这里可能需要根据实际版本查询mysql.role_edges或information_schema.applicable_roles等视图，但核心是查找具有特殊属性的角色），果然，我们发现了一个名为mysql_privileged_role的角色（这只是一个示例，实际名称可能不同），其属性被设置为了mandatory，也就是强制性的。

到这里,问题的脉络就清晰了，根据MySQL的官方文档（引用来源：MySQL 8.0 Reference Manual, Section 8.2.11, “Using Roles” and “Mandatory Roles”），强制角色是MySQL数据库系统本身定义的一种特殊角色，数据库管理员可以配置一些角色为强制角色，这些角色会自动地授予给每一个创建的用户，无需手动执行GRANT命令，这些角色通常包含一些最基础的系统级权限，用于保证用户具备最基本的连接或系统访问能力，设计强制角色的初衷是为了简化权限管理和确保基础安全策略的强制执行。

关键的限制就在于：这些强制角色是由数据库系统内部管理的，它们的权限集合是固定的，不允许通过外部的GRANT或REVOKE语句进行修改，这就像是你不能随意给操作系统自带的“Administrators”组增减权限一样，它的权限是由系统核心定义的，而我的这位同事的错误操作，正是试图将一个系统级的权限（SELECT ON *.*，这里的意味着对所有数据库的所有表）授予给一个已经被标记为强制角色的角色，MySQL系统检测到这个操作后，为了保护其内部权限结构的完整性和稳定性，便果断拒绝了该请求，并抛出了3897错误，明确告知“系统权限不能授予强制角色”。

理解了根源,解决方案就变得直接明了，我向他解释了强制角色的不可变性，我们需要的修正方案是放弃修改那个强制角色的想法，正确的做法是：他们应该使用自己创建的那个普通角色“app_read_only”，确认这个角色没有被错误地设置为强制角色（通常自己创建的默认不是），分两步走：第一步，将具体的、细粒度的对象权限（比如GRANT SELECT ON my_app_db.* TO 'app_read_only';）授予这个自定义角色；第二步，再将这个包含了所需权限的自定义角色授予给具体的应用程序用户（GRANT 'app_read_only' TO 'app_user';），别忘了让用户设置这个角色为默认角色，以便在连接时自动生效（SET DEFAULT ROLE 'app_read_only' TO 'app_user';）。

按照这个思路,我们修改了自动化脚本，去掉了那条试图向角色授予系统权限的错误语句，转而精确地授予数据库级别的对象权限，重新执行脚本后，一切顺利，权限被成功设置，应用程序也恢复了正常连接，这次远程协助不仅解决了一个技术报错，更重要的是，让团队对MySQL的角色模型，特别是强制角色这一高级特性有了更深刻的理解，避免了未来再次踏入同一个陷阱，整个修复过程的核心就在于区分系统管理的强制角色和用户自定义的普通角色，并只在后者上进行灵活的权限分配。