MySQL创建函数必须声明DETERMINISTIC、NO SQL或READS SQL DATA，否则报错1418；这是因启用binlog时为保障主从一致性和查询优化所设的硬性安全校验，三者需严格按函数实际行为选择，误标会导致缓存错误或复制不一致。
MySQL自定义函数不加DETERMINISTIC（或等效声明）会直接报错，根本无法创建；加了但乱加，可能让查询变慢甚至结果出错。
MySQL创建函数时为什么必须声明DETERMINISTIC、NO SQL或READS SQL DATA
这是硬性语法要求，不是可选项。如果你写完CREATE FUNCTION却没在函数体前加上三者之一，MySQL会立刻拒绝执行，并抛出错误：This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration。原因在于：MySQL需要明确该函数是否会影响数据一致性，尤其在主从复制、查询重写、执行计划缓存等场景下，必须提前知道它的“行为画像”。
常见对应关系：
- 纯数学计算、字符串处理（如
UPPER()、ROUND()类逻辑）→ 用DETERMINISTIC - 只查表、不改数据（如
SELECT COUNT(*) FROM orders WHERE user_id = ?）→ 用READS SQL DATA - 完全不碰数据库（比如仅调用
SIN()、CONCAT()）→ 用NO SQL
DETERMINISTIC声明被误用的真实后果
MySQL不会校验你声明的DETERMINISTIC是否真实成立——它全凭你“诚实申报”。这就埋下了隐患：
- 把实际查表的函数（比如根据用户ID查最新订单状态）错误声明为
DETERMINISTIC，优化器可能缓存第一次的结果，后续调用直接返回旧值，导致数据不一致 - 在主从复制中，如果主库上函数返回A，从库因缓存或执行时机差异返回B，就会破坏复制一致性
- 某些高级功能（如基于函数的索引）会强制要求
DETERMINISTIC，但若函数内部有NOW()、RAND()、子查询或依赖会变更的数据，即使声明了也无法真正支持索引构建
哪些函数其实不能标DETERMINISTIC但常被误标
这类误标在业务代码里高频出现，且很难被测试覆盖：
- 任何包含
SELECT ... FROM语句的函数，哪怕只读一行 —— 因为并发写入会让两次调用看到不同快照 - 调用
UUID()、RAND()、NOW()、SYSDATE()等内置非确定函数 - 引用用户变量（
@var）或会话系统变量（如@@time_zone） - 函数内调用另一个未声明特性的自定义函数（递归依赖链断裂）
典型反例：CREATE FUNCTION get_user_level(uid INT) RETURNS VARCHAR(10) DETERMINISTIC BEGIN RETURN (SELECT level FROM users WHERE id = uid); END; —— 表数据随时可能被UPDATE，这个函数绝不是确定性的。
真正安全的DETERMINISTIC函数长什么样
它必须满足：输入相同 → 输出绝对相同，且不依赖任何外部状态。例如：
DELIMITER // CREATE FUNCTION calc_vat(price DECIMAL(10,2)) RETURNS DECIMAL(10,2) DETERMINISTIC BEGIN RETURN price * 1.2; END// DELIMITER ;
这类函数才能被优化器放心地做常量折叠、结果缓存、甚至用于FUNCTION-BASED INDEX。一旦函数逻辑稍有“活”的成分（哪怕只是查了一张静态配置表），就该换用READS SQL DATA，而不是靠声明“骗过”MySQL。
最容易被忽略的一点是：函数是否确定，不取决于你写了什么SQL，而取决于它在运行时是否真的稳定。线上压测和灰度观察比语法检查更管用。
