set global log_bin_trust_function_creators = 1 不生效的主因是权限不足、作用域误解或持久性缺失；必须用system_variables_admin权限账号执行，仅影响新连接，重启失效，且需确认配置文件位置、格式及是否被正确加载。
SET GLOBAL log_bin_trust_function_creators = 1 不生效？先查权限
执行 SET GLOBAL log_bin_trust_function_creators = 1 返回 “Query OK” 却查不到效果，大概率不是命令写错，而是当前用户没权限。MySQL 对这个变量的修改要求严格：
- MySQL 8.0.12+ 必须拥有
SYSTEM_VARIABLES_ADMIN权限 - 旧版本（如 5.7）需
SUPER权限 -
CREATE ROUTINE权限完全不够用
验证方式：SELECT CURRENT_USER(), PRIVILEGE_CHECKS_USER(); + SHOW GRANTS;。若无对应权限，必须换 root 或已授权账号操作。
my.cnf 配置写对了却没加载？确认位置、段落和格式
log_bin_trust_function_creators = 1 必须放在 [mysqld] 段下，写在 [client]、[mysql] 或其他节里全无效。常见错误包括：
- 拼错参数名：比如
log-bin-trust-function-creators（带短横）、log_bin_trust_function_trust_creators（重复词） - 加引号或空格：
log_bin_trust_function_creators = "1"或= 1（末尾空格）都可能被忽略 - 配置文件路径不对：Docker 环境常在
/etc/mysql/conf.d/xxx.cnf，而非主my.cnf
查实际加载路径：mysqld --verbose --help | grep "Default options"；MySQL 8.0.25+ 还可直接查：SELECT @@GLOBAL.config_file;。
设置了还是报 ERROR 1418？函数本身没声明特性
ERROR 1418 (HY000) 的本质是 MySQL 拒绝创建未声明安全特性的函数。log_bin_trust_function_creators = 1 只绕过权限检查，不解决函数是否安全——它只是“信任创建者”，不是“豁免函数定义”。真正要做的：
- 给函数显式声明
DETERMINISTIC、READS SQL DATA或NO SQL，例如：CREATE FUNCTION f() RETURNS INT READS SQL DATA BEGIN ... END - 确认
binlog_format是STATEMENT（ROW模式下此参数基本无影响） - 检查函数是否真能被识别：
SELECT ROUTINE_NAME FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = 'your_db';—— 升级到 MySQL 8.0 后若mysql.proc表未迁移，函数元数据可能已丢失
云数据库或容器环境不能直接改配置？走平台参数组或启动参数
阿里云 RDS、AWS RDS、Azure Database for MySQL 等云服务不允许直接编辑 my.cnf。此时必须：
- 通过控制台进入「参数组」或「服务器参数」页面，找到
log_bin_trust_function_creators并设为ON或1 - 保存后按平台要求「应用变更」——注意：Azure 灵活服务器等静态参数需重启实例才生效
- Docker 启动时可通过
--log-bin-trust-function-creators=1传参，或挂载自定义.cnf到/etc/mysql/conf.d/
动态设置 SET GLOBAL 在云环境中通常被禁用，且即使成功也仅对新连接生效，重启即丢——别指望它长期兜底。
