普通用户调用自定义函数失败主因是definer用户不存在、权限不全或sql security冲突；须用show create function查definer和security类型，验证其存在性及对基表、系统变量（8.0+需system_variables_admin）、跨库对象的最小必要权限，优先修复definer而非改invoker。
普通用户调用自定义函数失败，几乎从来不是因为调用者缺 EXECUTE 权限，而是函数的 DEFINER 用户不存在、权限不全，或 SQL SECURITY 模式与实际环境冲突——直接给调用者授一堆权限，基本白忙。
查清函数的 DEFINER 和 SQL SECURITY 类型
执行 SHOW CREATE FUNCTION function_name;，重点看两行输出：
-
DEFINER=`user`@`host`—— 这个账号在当前 MySQL 实例里是否存在？比如'nobody'@'%'或迁移后已删除的账号，就是典型病根 -
SQL SECURITY DEFINER（默认值）—— 表示函数运行时完全按DEFINER身份校验权限；如果没写这句，MySQL 仍按DEFINER模式执行 - 若看到
SQL SECURITY INVOKER，才需要检查当前调用者的权限，但这种情况极少，且运维成本高
验证 DEFINER 用户是否存在且权限完整
别只查 CURRENT_USER()，要盯死定义者本身：
- 用
SELECT User, Host FROM mysql.user WHERE User = 'user' AND Host = 'host';确认账号真实存在（注意大小写和Host字段必须完全匹配） - 执行
SHOW GRANTS FOR 'user'@'host';，确认它拥有函数体里所有操作涉及的权限：- 对每张基表的
SELECT/UPDATE等最小必要权限（GRANT SELECT ON db.*不等于能访问db.table，MySQL 是逐表校验） - 若函数读取系统变量（如
@@version或@@sql_mode），MySQL 8.0+ 必须授予SYSTEM_VARIABLES_ADMIN（不是SUPER） - 跨库操作时，
DEFINER必须对每个目标库都单独授权，不能只授一个库
- 对每张基表的
修复 DEFINER 权限比改 SQL SECURITY 更可靠
优先修 DEFINER，而不是把函数改成 INVOKER：
- 用高权限账号（如
root）执行：GRANT SELECT ON target_db.target_table TO 'definer_user'@'%'; - 若涉及系统变量：
GRANT SYSTEM_VARIABLES_ADMIN ON *.* TO 'definer_user'@'%'; - 切忌
GRANT ALL PRIVILEGES—— 最小化授权，避免权限膨胀 - 改完立即测试：
SELECT function_name();，别等应用报错才验证 - Docker 或云数据库（如阿里云 RDS）中，
log_bin_trust_function_creators常被默认关闭，导致函数根本无法创建或调用，需显式开启
最易被忽略的是：函数内哪怕只调用了一个系统变量、或跨了一次库查询，DEFINER 就必须有对应权限，而这些权限不会继承、不会通配、也不会自动补全。
