MySQL 8.0角色本身不支持审批流程，因其权限模型为纯静态、原子化授权，无状态流转、日志记录或元信息携带能力；需依赖外部系统（如审批表、定时任务、应用网关）构建完整闭环。
MySQL 8.0 的角色（ROLE）本身不支持“审批流程”，必须靠外部机制或人工操作补足；角色只管“权限集合的定义与分发”，不提供状态流转、待批队列、审批日志等能力。
为什么不能直接用 GRANT + ROLE 实现审批
MySQL 权限系统是纯静态授权模型：执行 GRANT 'role_name' TO 'user'@'host' 就立即生效，没有中间态。它不记录“谁申请了”“谁批准了”“何时过期”，也不拦截未审批的授权请求。所谓“审批体系”，本质是业务流程层的事，数据库只负责最终落库那一瞬的权限开关。
- 所有权限变更（包括角色授予）都是原子操作，不可回滚到“待审批”状态
-
SHOW GRANTS查不到申请来源、审批人、时间戳——这些需额外建表记录 - 角色无法携带元信息（如
approval_status、expires_at），也不能触发存储过程自动校验 - 即使你封装了一个
APPROVE_ROLE_GRANT()存储过程，它也只是把GRANT包了一层，仍不具备审计闭环能力
如何用角色 + 外部机制搭出可落地的审批流
真正的分级审批要靠“角色定义 + 状态表 + 定时任务/应用网关 + 权限同步”四件套组合实现：
- 在业务系统中建一张
role_approval_request表，字段含request_id、user_host、target_role、status（pending/approved/rejected）、approver、approved_at - 审批通过后，由运维脚本或审批平台调用 MySQL 执行
GRANT 'marketing_admin' TO 'zhangsan'@'10.0.2.%'和SET DEFAULT ROLE 'marketing_admin' TO 'zhangsan'@'10.0.2.%' - 禁止任何人直连数据库执行
GRANT，所有权限变更必须走审批平台接口——这是控制入口的关键 - 用定时任务每 5 分钟查一次
role_approval_request WHERE status = 'approved' AND applied = 0，执行完更新applied = 1，避免重复执行 - 敏感角色（如
db_admin）可配置为“双人审批”，即status需两次不同账号的UPDATE才能变approved
角色分级设计必须避开的三个坑
很多团队以为“建几个角色就叫分级了”，结果上线后权限失控。真正可用的分级，得从语义和约束两头卡死：
-
角色名必须带层级前缀，比如
l1_app_reader、l2_app_writer、l3_db_admin，而不是reader、writer——否则无法靠命名快速识别权限边界，也难做自动化策略匹配 -
禁止跨级继承：不要
GRANT 'l2_app_writer' TO 'l1_app_reader'。角色嵌套只用于职能复用（如audit_role套l1_app_reader），不是用来模拟组织树。MySQL 不支持 A→B→A 循环，但更危险的是人为搞出隐式越权路径 -
所有角色必须显式禁用高危权限：创建
l1_app_reader后，立刻执行REVOKE FILE, SHUTDOWN, SUPER ON *.* FROM 'l1_app_reader'。因为角色默认不继承全局权限，但一旦某天有人误给该角色加了SELECT ON *.*，再不显式回收，就会穿透到系统库
权限生效延迟与连接认证的隐性冲突
即使审批完成、GRANT 执行成功，用户仍可能拿不到权限——这不是审批没走完，而是 MySQL 连接层没加载角色：
- 用户已设
SET DEFAULT ROLE 'l2_app_writer' TO 'user'@'%'，但用旧版客户端（如 MySQL 5.7 客户端连 8.0 服务端）会因认证插件不兼容，导致角色根本没加载，CURRENT_ROLE()返回NONE - 应用使用连接池（如 HikariCP）时，老连接不会自动重载角色，必须重启连接或配置
connection-init-sql=SET ROLE 'l2_app_writer' -
FLUSH PRIVILEGES对角色无效，但如果你混用了直接改mysql.role_edges表的方式（不推荐），就必须执行它，否则角色关系不刷新
最易被忽略的点是：角色权限只在会话级生效，且依赖于用户连接时的认证上下文。没有统一的连接初始化逻辑，审批再严谨，也会在某个凌晨三点的长连接里失效。
