SET GLOBAL log_bin_trust_function_creators = 1 不生效的主因是权限不足、作用域误解或持久性缺失；必须用 SYSTEM_VARIABLES_ADMIN 权限账号执行，仅影响新连接，重启失效，且需确认配置文件位置、格式及是否被正确加载。
SET GLOBAL log_bin_trust_function_creators = 1 不生效的常见原因
这不是语法写错了，而是权限、作用域或持久性三者中至少一个没对上。最常被忽略的是：普通用户执行 SET GLOBAL 命令时，MySQL 会静默忽略，SHOW VARIABLES LIKE 'log_bin_trust_function_creators' 仍显示 OFF，但命令返回“Query OK”造成误判。
必须用具备 SYSTEM_VARIABLES_ADMIN 权限的账号（如 root）执行；临时设置只影响后续新连接，当前会话不受影响；且 MySQL 重启后该值自动回退为 0。
- 检查执行者权限：
SELECT CURRENT_USER(), PRIVILEGE_CHECKS_USER(); - 确认是否真正生效：
SELECT @@global.log_bin_trust_function_creators;（不能只看@@session） - 如果返回 0，说明设置未落地，不是“没反应”，而是压根没成功
my.cnf 配置了但重启后仍是 OFF
配置项写错位置或格式不合法是主因。这个参数必须放在 [mysqld] 段下，且不能带引号、不能有空格、不能拼错名字——比如写成 log_bin_trust_function_trust_creators 或 log-bin-trust-function-creators 都无效。
还要确认配置文件路径正确：Docker 容器里可能是 /etc/mysql/conf.d/xxx.cnf，RDS 或云数据库根本不允许修改配置文件，只能通过控制台参数组操作。
- 运行
mysqld --verbose --help | grep "Default options"查看 MySQL 实际加载的配置文件路径 - 启动后执行
SELECT @@GLOBAL.config_file;（8.0.25+ 支持），验证是否读到了你改的文件 - 检查错误日志：
tail -n 50 /var/log/mysql/error.log，常有类似unknown variable 'log_bin_trust_function_creators=1'的提示
为什么 SHOW CREATE FUNCTION 看不到函数，却提示 log_bin_trust_function_creators 报错？
这是典型的因果倒置。报错 ERROR 1418 (HY000) 表明你正在尝试创建函数，但 MySQL 拒绝了；而函数“消失”是另一回事——比如从 MySQL 5.7 升级到 8.0 时，mysql.proc 表未迁移成功，函数定义已从数据字典中清空，此时再怎么开 log_bin_trust_function_creators 也无济于事。
- 先查函数是否存在：
SELECT ROUTINE_NAME FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = 'your_db'; - 若结果为空，说明函数已丢失，和配置无关，需从备份或旧实例恢复
CREATE FUNCTION语句 - 若存在但创建失败，才回到权限和配置排查路径
根本不需要开这个参数的替代方案
设为 1 是绕过检查，不是解决问题。真正安全的做法是让函数“自证清白”：显式声明确定性。哪怕函数逻辑确实依赖 NOW()，只要业务接受“主从时间差导致复制延迟内结果不同”，就应在定义时加上 READS SQL DATA 或 DETERMINISTIC ——后者虽不改变行为，但满足 binlog 安全策略。
- 正确声明示例：
CREATE FUNCTION calculate_score(...) RETURNS DECIMAL ... READS SQL DATA ... -
NO SQL适用于纯计算不查表的函数，READS SQL DATA适用于只读不写的函数，都比开log_bin_trust_function_creators更可控 - 生产环境应禁用该参数，靠声明而非信任；开发环境若批量调试，也建议仅在专用测试实例的配置文件中开启，并明确注释失效条件
最容易被忽略的一点：这个参数只影响函数/触发器的「创建」动作，对已存在的对象完全无感。如果你在修复一个已上线却突然报错的函数，第一反应不该是调这个参数，而是检查它是否被重建过、是否在升级后被自动删除、或者是否因权限变更导致定义不可见。
