mysql原生不支持仅授权调用某几个函数的细粒度控制；8.0.16+虽支持grant execute on function语法但需先授usage且仍无法解决函数内部权限问题，兼容性差；推荐做法是将开放函数统一放入专用库（如api_functions），再授grant execute on api_functions.*。
MySQL 原生不支持“只允许调用某几个函数”的细粒度授权
直接回答：你不能用 GRANT EXECUTE ON FUNCTION db.func_a 单独授权一个函数，然后拒绝 func_b——除非你用的是 MySQL 8.0.16+，且先授了 USAGE，但即便如此，它也只控制“能否调用”，不解决函数内部权限问题。更关键的是，GRANT EXECUTE ON FUNCTION 语法在 5.7 及更早版本会直接报 ERROR 1064 (42000)，根本不可用。
所以别指望靠一条 GRANT 语句实现白名单式函数调用控制。真正能落地的做法是结构隔离 + 权限收敛：
- 把所有要开放的函数统一放进专用库（比如
api_functions），只对这个库授EXECUTE：GRANT EXECUTE ON `api_functions`.* TO 'appuser'@'%' - 禁止给
*.*授EXECUTE，否则用户能调用任意库里的任意函数，包括系统库中可能被滥用的 UDF - 删掉不用的函数，尤其是带
sys_、lib_mysqludf前缀的 UDF，用SELECT * FROM mysql.func WHERE name LIKE '%sys%'检查
函数调用失败却报 “EXECUTE command denied” 的真实原因
这个错误信息极具误导性——它不是说“你不准调这个函数”，而是 MySQL 在执行函数体内的某条 SQL 时卡住了，但统一归为“EXECUTE 权限不足”。常见真凶有：
- 函数里写了
SELECT * FROM otherdb.users，但用户没被授予otherdb库的SELECT权限 - 函数定义用了
SQL SECURITY DEFINER，但定义者账号已被删或无权访问目标表（此时 fallback 到调用者权限校验） - 函数用了动态 SQL（
PREPARE/EXECUTE），MySQL 会按调用者权限检查语句中涉及的表名，哪怕定义者权限再高也没用 - 授权 host 不匹配：授的是
'appuser'@'localhost'，但应用连的是'appuser'@'127.0.0.1'（MySQL 视为两个账号）
排查时别只看 SHOW GRANTS，得结合 SHOW CREATE FUNCTION func_name 看定义者、安全上下文，再查 INFORMATION_SCHEMA.ROUTINES 确认函数归属库和字符集是否一致。
为什么不能依赖角色（role）做函数级白名单
MySQL 的 role 是库级容器，不是对象级策略引擎。你可以建一个 role：CREATE ROLE func_reader，再 GRANT EXECUTE ON `api_functions`.* TO func_reader，但它依然无法过滤到具体函数名。一旦用户拥有该 role，就能调用 api_functions 下所有函数——包括你后来新增的、未预期的函数。
更麻烦的是，role 的权限继承关系会让审计变复杂。比如 func_reader 被授予给了 appuser，而 appuser 又被其他脚本误加了 EXECUTE ON *.*，那整个白名单机制就形同虚设。生产环境建议绕过 role，直接用库级授权 + 定期巡检 mysql.procs_priv 表（如果启用过过程级权限）。
最常被忽略的权限盲区：函数体内 SQL 的隐式权限依赖
哪怕你把函数放到专用库、只授 EXECUTE、定义者权限也完整，只要函数里有一行 INSERT INTO log_table，而用户没被授予 log_table 的 INSERT 权限，调用就会失败，并报那个熟悉的 EXECUTE command denied。MySQL 不会在报错里告诉你缺的是哪张表、哪个权限。
所以每次上线新函数，必须人工确认两点：函数体里所有 DML/DDL 涉及的库表，用户是否都具备对应权限；若用了 INTO OUTFILE 或 LOAD_FILE()，还要额外检查 FILE 权限是否被 REVOKE 过。自动化手段有限，靠文档 + 上线 checklist 最实际。
