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。
GRANT EXECUTE ON PROCEDURE 语法是否生效取决于 MySQL 版本
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（含函数），不是“仅过程”
EXECUTE 权限不等于数据访问权，DEFINER 模式常导致误判
即使 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'，而该账号已被删或权限回收，过程就失效 - 过程内用了动态 SQL 或跨库表（如
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 配合改定义。
