MySQL 8.0.16+ 支持 GRANT EXECUTE ON PROCEDURE db_name.proc_name,但需先授 USAGE 权限;5.7 及更早版本不支持该语法,执行即报 ERROR 1064。
只给 EXECUTE 权限就能让开发者调用存储过程,但必须精确到 PROCEDURE db_name.proc_name,且 MySQL 8.0.16+ 才真正支持该语法;5.7 及更早版本会直接报错 ERROR 1064。
MySQL 5.7 不识别 GRANT EXECUTE ON PROCEDURE 写法,执行即报错;8.0.16+ 才正式支持,但有硬性前提:
USAGE 权限:GRANT USAGE ON `mydb`.* TO 'dev'@'%'
GRANT EXECUTE ON PROCEDURE calc_score TO ... 错误(缺库名)GRANT EXECUTE ON PROCEDURE mydb.* 是非法语法GRANT EXECUTE ON mydb.*,授的是整个库下所有 routine(含函数),不是“仅过程”即使 GRANT EXECUTE 成功,CALL mydb.sync_data() 仍可能报 ERROR 1370 (42000): execute command denied —— 这往往不是权限没给,而是:
SQL SECURITY DEFINER,内部 SQL 以 DEFINER 账号身份检查表权限,而非调用者SHOW CREATE PROCEDURE mydb.sync_data 查 DEFINER 字段,若为 'dba'@'localhost',而该账号已被删或权限回收,过程就失效other_db.users),但 DEFINER 对那些库没权限'dev'@'10.0.1.%',但实际连的是 'dev'@'localhost',MySQL 视为不同用户只给 EXECUTE,不给 ALTER ROUTINE,开发者就无法 SHOW CREATE PROCEDURE 或修改过程 —— 这是权限分离的正常表现:
EXECUTE:允许 CALL,不涉及查看、删除、重建ALTER ROUTINE:包含查看定义、修改、删除能力,慎授,普通开发者不需要GRANT SELECT ON mysql.proc 或 INFORMATION_SCHEMA.ROUTINES 替代 —— 这会让用户看到所有库的过程定义,严重越权CALL mydb.get_user_summary(),而不是依赖 SHOW GRANTS(它在某些授权粒度下根本不显示 EXECUTE)真正难控制的不是“能不能执行”,而是“执行时到底以谁的身份查哪张表”。SQL SECURITY INVOKER 才能让权限校验落在调用者身上,但这需要重建过程,且开发者通常没 ALTER ROUTINE 权限 —— 最终还得 DBA 配合改定义。