存储过程中不能直接使用grant语句，必须通过prepare+execute执行动态sql，且调用者须具备grant option权限；mysql编译期即校验dcl语法，grant不支持变量，角色名需加引号，用户与角色存在性需前置校验，事务控制和重连提示不可或缺。
不能直接在存储过程中用 GRANT 语句分配角色或权限——语法报错是必然结果，唯一可行路径是 PREPARE + EXECUTE 拼接动态 SQL，并且调用者必须拥有 GRANT OPTION 权限。
为什么 GRANT role_name TO user_name 在存储过程里一定失败
MySQL 在编译存储过程时就做 DCL 语句语法校验，GRANT 不接受变量作为标识符。写成 GRANT @role TO @user 会直接触发 ERROR 1064 (42000)，根本不会进入运行阶段。这不是权限问题，是语法硬限制——所有 GRANT、REVOKE、SET DEFAULT ROLE 都不支持变量直传。
- MySQL 5.7 完全不识别
ROLE关键字，强行使用会报错ERROR 1235，实际是版本不兼容 - MySQL 8.0+ 角色名必须加引号（如
'app_reader'@'%'），拼接时漏掉单引号会触发ERROR 1141 - 即使字符串拼对了，若用户或角色不存在，
EXECUTE仍会报错，且错误信息不直观（比如提示“no such grant”而非“user not found”）
安全执行动态授权的最小必要步骤
绕过语法限制后，真正落地还要防注入、保原子性、控权限边界。以下四步缺一不可：
- 显式声明
SQL SECURITY DEFINER，否则按调用者权限检查，大概率因缺少GRANT OPTION而失败 - 用
SELECT COUNT(*) FROM mysql.user WHERE User = ? AND Host = ?校验用户存在；用SELECT COUNT(*) FROM mysql.role_edges WHERE TO_USER = ?（或mysql.roles表）确认角色已创建 - 拼接 SQL 时全部用
CONCAT()，角色名和用户名必须包裹单引号：CONCAT("GRANT '", role_name, "' TO '", user_name, "'@'", host_name, "'") - 执行前加事务控制：
START TRANSACTION→PREPARE→EXECUTE→COMMIT或ROLLBACK，避免部分成功导致状态不一致
FLUSH PRIVILEGES 在存储过程中没用，用户重连才是关键
权限变更后，已建立的连接看不到新角色，因为 MySQL 不会主动刷新会话级权限缓存。FLUSH PRIVILEGES 只更新服务端内存中的权限表快照，不影响客户端当前连接的权限上下文。
- 存储过程末尾加
FLUSH PRIVILEGES是无效操作，纯属误导 - 正确做法是返回提示：例如
SELECT 'User must reconnect to apply new role' AS message; - 若需验证分配结果，可用
SELECT * FROM information_schema.role_table_grants WHERE GRANTEE = CONCAT('''', user_name, '''@''%', '''')，但这查的是元数据，不是实时生效状态 - 生产环境应配套运维流程：权限分配后自动通知用户重连，或由应用层在下次连接池重建时自然生效
最易被忽略的点是动态 SQL 的权限检查机制——即使 DEFINER 有足够权限，PREPARE+EXECUTE 的执行阶段仍按调用者身份做权限校验。这意味着：调用者账号本身必须拥有 GRANT OPTION，光靠 DEFINER 不够。
