MySQL存储过程编译报错1418无确定性标记如何解决-mysql教程-PHP中文网

报错1418是因binlog开启时mysql强制要求function显式声明deterministic、no sql或reads sql data属性，否则拒绝创建以保障主从一致；常见于工具执行、docker或mysql 8.0+默认启binlog场景。

mysql存储过程编译报错1418无确定性标记如何解决

直接说结论：报错1418不是权限问题，也不是语法写错了，而是 MySQL 在 binlog 开启时强制要求你为存储函数（FUNCTION）显式声明行为属性——否则它拒绝创建，以防主从数据不一致。

为什么 `CREATE FUNCTION` 会触发 ERROR 1418

只要你的 MySQL 实例开启了 binlog（即 log_bin=ON），而你又没在 CREATE FUNCTION 语句里写 DETERMINISTIC、NO SQL 或 READS SQL DATA 中的任意一个，就会立刻报这个错。这不是“可能出问题”，而是 MySQL 复制机制的硬性校验。

常见触发场景：

用 Navicat / DBeaver / SQLyog 等工具执行建函数脚本时弹窗报错
Docker 启动的 MySQL 默认开启 binlog，本地开发一建函数就崩
MySQL 8.0+ 新实例默认启用 binlog，新手照着教程复制 CREATE FUNCTION 直接失败

三种解法，优先级从高到低

别急着开全局开关，先看函数本身能不能安全标注：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

如果函数逻辑纯计算（比如 RETURN a * b + 1），不查表、不调系统函数，加 DETERMINISTIC 最稳妥
如果函数只做 SELECT 查询（如统计某张表数量），加 READS SQL DATA
如果函数完全不碰数据库（比如字符串处理、日期格式化），加 NO SQL
避免滥用 DETERMINISTIC：函数里用了 NOW()、RAND()、UUID() 或子查询，就不能标这个——MySQL 不校验真假，但主从可能不一致

示例（合法且安全）：

CREATE FUNCTION calc_discount(price DECIMAL(10,2), rate TINYINT) 
RETURNS DECIMAL(10,2)
DETERMINISTIC
BEGIN
  RETURN price * (1 - rate / 100);
END;

`log_bin_trust_function_creators=1` 怎么设才真正生效

这个变量是“绕过检查”的开关，但它有坑：

SET GLOBAL log_bin_trust_function_creators = 1 只对后续新连接生效，当前会话已报错不会回滚
需要 SYSTEM_VARIABLES_ADMIN 或 SUPER 权限，普通 CREATE ROUTINE 权限不够
MySQL 重启后失效，必须写进配置文件才持久：在 my.cnf 的 [mysqld] 段加一行 log-bin-trust-function-creators=1（注意是短横线，不是下划线）
生产环境慎用：一旦开启，任何用户都能创建未声明属性的函数，binlog 重放时可能产生不可预期结果