set global log_bin_trust_function_creators = 1 不生效的主因是权限不足、作用域误解或持久性缺失；必须用 system_variables_admin 权限账号执行，仅影响新连接，重启失效，且需确认配置文件位置、格式及是否被正确加载。
SET GLOBAL 不生效，大概率是权限不对
执行 SET GLOBAL log_bin_trust_function_creators = 1 返回 “Query OK” 但查不到效果，不是命令写错，而是当前用户没权限。MySQL 对这个变量的修改要求严格：必须拥有 SYSTEM_VARIABLES_ADMIN 权限（MySQL 8.0.12+）或 SUPER 权限（旧版本）。普通 DBA 账号即使有 CREATE ROUTINE 也不行。
验证方式：SELECT CURRENT_USER(), PRIVILEGE_CHECKS_USER(); 然后查权限：SHOW GRANTS;。若无对应权限，需用 root 或已授权账号操作。
注意：SET GLOBAL 只影响新建立的连接，当前会话不变；MySQL 重启后自动还原为 0。
my.cnf 配置写对了却没加载，先确认文件路径和段落
配置项 log_bin_trust_function_creators = 1 必须放在 [mysqld] 段下，不能写在 [client] 或其他节里；也不能加引号、空格或拼错名（比如写成 log-bin-trust-function-creators 或 log_bin_trust_function_trust_creators 都无效）。
检查 MySQL 实际加载的配置文件路径：mysqld --verbose --help | grep "Default options"；8.0.25+ 还可运行 SELECT @@GLOBAL.config_file; 直接查路径。
Docker 环境常见坑：配置文件可能在 /etc/mysql/conf.d/xxx.cnf，而非主 my.cnf；云数据库（如阿里云 RDS、AWS RDS）根本不允许直接改配置文件，只能通过控制台“参数组”修改并应用。
设置了还是报 ERROR 1418，先别急着调参
报错 ERROR 1418 (HY000) 的本质是 MySQL 拒绝创建未声明特性的函数，但很多人误以为只要开了 log_bin_trust_function_creators 就万事大吉——其实它只绕过权限检查，不解决函数本身是否安全。
真正该做的三件事：
- 给函数显式声明
DETERMINISTIC、READS SQL DATA或NO SQL（例如：CREATE FUNCTION f() RETURNS INT READS SQL DATA ...） - 确认 binlog_format 是
STATEMENT（ROW模式下此参数基本无影响） - 查函数是否真存在：
SELECT ROUTINE_NAME FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = 'your_db';—— 升级到 MySQL 8.0 后，若mysql.proc表未迁移，函数定义可能已丢失，此时开参数也无效
要不要开？取决于你敢不敢担复制风险
log_bin_trust_function_creators = 1 不是功能开关，而是安全妥协。它允许非确定性函数（比如含 NOW()、RAND()、UUID() 的函数）被写入 binlog，在 STATEMENT 复制模式下，从库执行结果很可能与主库不同，造成数据漂移。
线上环境建议：
- 开发/测试库可临时开启，但上线前必须补全函数特性声明
- 生产主从架构中，优先改用
ROW复制模式（此时该参数失效，且更安全） - 若必须用
STATEMENT+ 自定义函数，应确保所有函数都标DETERMINISTIC，并经充分验证
最常被忽略的一点：这个参数也控制触发器创建行为，而不仅仅是函数——改完别忘了同步检查触发器逻辑是否仍可靠。
