mysql函数执行权限由execute权限控制，创建需create routine和alter routine，且sql security definer机制可能导致提权风险。
MySQL 函数执行权限由哪些权限控制
MySQL 中函数的调用（EXECUTE）和创建（CREATE ROUTINE）是分离的，不能靠 SELECT 或 USAGE 权限代替。用户要能调用自定义函数，必须显式授予 EXECUTE 权限；要能创建函数，还需 CREATE ROUTINE 和 ALTER ROUTINE（修改时用），且全局 super_priv 或 system_variables_admin（8.0.16+）可能影响函数内访问系统变量的行为。
-
EXECUTE权限可按数据库级（db_name.*）或函数级（db_name.func_name）授予，后者更精细 - 仅授予
SELECT权限给函数所属数据库，**不会**自动允许调用该函数 - 函数体中若含
SQL SECURITY DEFINER（默认），则执行时以定义者权限检查，而非调用者——这是提权风险点
如何安全地授予函数调用权限（避免越权）
最常用也最可控的方式是按函数粒度授权，而不是开放整个数据库的 EXECUTE：
GRANT EXECUTE ON FUNCTION mydb.calc_discount TO 'app_user'@'10.20.30.%';
如果函数依赖特定表读写，还要同步确认调用者是否具备对应表的 SELECT/INSERT 等权限——函数内部的 SQL 仍受这些权限约束。
- 禁止对生产账号授予
GRANT OPTION，否则可能被用来扩散EXECUTE权限 - 避免使用
SQL SECURITY DEFINER除非必要；如必须用，定义者账号应是低权限专用账号（比如只拥有函数所需那几张表的权限） - MySQL 8.0+ 可结合角色（
ROLE）统一管理函数权限，例如：CREATE ROLE func_reader;<br>GRANT EXECUTE ON FUNCTION mydb.get_user_status TO func_reader;<br>GRANT func_reader TO 'api_worker'@'%';
常见权限失效场景与排查方法
即使执行了 GRANT，调用函数仍报 ERROR 1370 (42000): execute command denied，多数是因为以下原因：
- 未执行
FLUSH PRIVILEGES;—— 一般不需要，但如果你直接改了mysql.proc表（不推荐），就必须刷 - 用户名或 host 不匹配：检查
SELECT User, Host FROM mysql.user WHERE User = 'xxx';，注意'user'@'localhost'和'user'@'127.0.0.1'是不同账号 - 函数名大小写敏感：Linux 下函数名区分大小写，
GRANT EXECUTE ON FUNCTION mydb.MyFunc和调用mydb.myfunc()会失败 - 函数属于另一个数据库但没指定库名：调用时写成
otherdb.my_func()，但权限只给了mydb.my_func→ 必须权限名与调用名完全一致
函数权限与安全模式（sql_mode）的隐性关联
MySQL 启用 NO_AUTO_CREATE_USER（已弃用）或严格模式本身不影响函数权限，但一个关键限制常被忽略：当 log_bin = ON（即开启 binlog）时，函数若含非确定性操作（如 NOW()、UUID()、子查询等），默认不允许创建，除非显式声明 DETERMINISTIC 或设置 sql_log_bin = OFF（不推荐）。这不是权限问题，但会导致 CREATE FUNCTION 失败，让人误以为是权限不足。
- 检查当前限制：
SELECT @@log_bin, @@sql_mode;
- 创建确定性函数示例：
CREATE DEFINER = 'admin'@'%' FUNCTION mydb.add_tax(price DECIMAL(10,2))<br>RETURNS DECIMAL(10,2)<br>READS SQL DATA<br>DETERMINISTIC<br>BEGIN RETURN price * 1.08; END;
- 若函数确实需非确定性逻辑（如生成唯一 ID），应考虑改用存储过程 + 应用层控制，或关闭 binlog（仅限开发/测试环境）
函数权限真正难控的点不在授权语句本身，而在于 SQL SECURITY DEFINER 的隐式权限继承和 binlog 对函数创建的静默拦截——这两处最容易在上线后暴露问题。
