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 对函数创建的静默拦截——这两处最容易在上线后暴露问题。
