MySQL存储过程中需用PREPARE+EXECUTE执行动态GRANT语句，调用者须有GRANT OPTION权限，显式声明SQL SECURITY DEFINER，并校验角色/用户存在、严格过滤输入防注入，8.0+角色名需加引号，权限变更后需用户重连生效。
MySQL存储过程中怎么安全地执行动态SQL分配角色
直接用 GRANT 语句在存储过程中报错是常态，因为 MySQL 默认禁止在存储过程里执行需要 SUPER 权限的权限操作，而且 GRANT 不支持变量占位。真正能走通的路只有一条：用 PREPARE + EXECUTE 拼接并执行动态 SQL，且调用者必须拥有对应权限（不是存储过程定义者权限）。
- 必须显式声明
SQL SECURITY DEFINER，否则执行时按调用者权限检查，大概率失败 - 角色名、用户名都得用
CONCAT()拼进字符串，不能直接写变量——比如SET @sql = CONCAT('GRANT ', role_name, ' TO ', user_name) - 执行前务必校验输入：用
SELECT COUNT(*) FROM mysql.role_edges确认角色存在，用SELECT COUNT(*) FROM mysql.user确认用户存在，否则EXECUTE报错不友好 - 注意 MySQL 8.0+ 的角色名要带引号（如
'app_reader'@'%'），拼接时漏掉引号会触发ERROR 1141 (42000): There is no such grant defined for user
为什么存储过程里不能直接用 GRANT role_name TO user_name
因为 GRANT 是 DCL 语句，MySQL 在存储过程编译期就做语法校验，它不接受标识符变量（identifier variable）。你写 GRANT @role TO @user 会直接报 ERROR 1064 (42000)，提示语法错误——它连解析都过不去，更别说运行时替换。
- 所有涉及权限变更的操作（
GRANT、REVOKE、SET DEFAULT ROLE）都不能用变量直传 - 替代方案只有字符串拼接 +
PREPARE/EXECUTE，且该存储过程必须由有GRANT OPTION的账号创建，并用DEFINER执行 - MySQL 5.7 不支持角色，强行用会报
ERROR 1235 (42000): This version of MySQL doesn't yet support 'multiple triggers with the same action time and event for one table'类似误导性错误，实际是语法不识别ROLE关键字
存储过程分配角色后，用户为什么立刻看不到新权限
因为权限缓存没刷新。MySQL 不会自动重载权限表，新分配的角色对已存在的连接无效，必须显式执行 FLUSH PRIVILEGES 或让用户重新登录。
- 在存储过程末尾加
FLUSH PRIVILEGES没用——它只影响服务端内存缓存，不影响客户端连接的权限上下文 - 正确做法是在存储过程里用
SELECT查information_schema.role_table_grants或performance_schema.accounts做结果确认，但别指望它反映实时生效状态 - 如果用户正在用长连接，必须通知其断开重连；自动化场景建议搭配应用层 session 重建逻辑
- 注意
FLUSH PRIVILEGES本身不是原子操作，高并发下可能短暂出现权限不一致，生产环境慎用于关键路径
如何避免动态 SQL 引发 SQL 注入风险
用户输入的角色名或用户名如果未经处理就拼进 PREPARE 字符串，等于把权限控制大门敞开。MySQL 没有参数化 DCL 语句的支持，只能靠白名单 + 格式校验双保险。
- 强制要求角色名匹配正则
^[a-zA-Z0-9$_]+$，用REGEXP函数过滤，拒绝含点、@、反引号、空格的输入 - 用户名必须包含
@，且主机段只允许%、localhost或 IP 段（如192.168.1.%），用SUBSTRING_INDEX(user_name, '@', 1)和SUBSTRING_INDEX(user_name, '@', -1)分离校验 - 拼接前用
QUOTE()包裹字符串值——它会自动加单引号并转义内部引号，比手写CONCAT("'", var, "'")安全得多 - 不要在存储过程中拼接数据库名或表名做权限授予，这类操作应提前固化配置，运行时只查表不拼 SQL
