MySQL自定义函数修改后不会自动生效
直接执行
CREATE OR REPLACE FUNCTION并不能更新已存在的函数，MySQL 会报错
ERROR 1304 (42000): FUNCTION xxx already exists。必须先用
DROP FUNCTION删除，再重新
CREATE FUNCTION，否则调用的仍是旧逻辑。
常见误操作是只改了 SQL 文件或开发环境里的定义，没在目标实例上真正执行删除+重建——这时查
mysql.func表或
SHOW FUNCTION STATUS都会显示旧的
created和
modified时间戳。
MySQL 5.7 与 8.0 在函数解析上的关键差异
MySQL 8.0 引入了原子 DDL 日志，
DROP FUNCTION+
CREATE FUNCTION是原子操作；而 5.7 下这两步是分离的，若中间出错（如权限不足、磁盘满），会导致函数处于“不存在但调用时报错”的中间态。
另外，8.0 默认开启
sql_mode=STRICT_TRANS_TABLES，若函数体内有隐式类型转换（比如把
VARCHAR当
INT用），5.7 可能静默截断，8.0 会直接报
ERROR 1265 (01000): Data truncated for column。
DELIMITER必须在
CREATE FUNCTION前重设，尤其在脚本批量执行时，漏写会导致语法错误 函数体中若含
SELECT ... INTO，需确保目标变量已声明，8.0 对未声明变量报错更严格 跨版本迁移函数时，注意 8.0 移除了
DATA DIRECTORY和
INDEX DIRECTORY语法支持
验证函数是否真的更新成功
不能只看执行成功提示，要从三个层面确认：
查元数据：SELECT name, created, modified FROM mysql.proc WHERE type = 'FUNCTION' AND name = 'your_func_name'，对比
created和
modified是否为最新时间 看定义：
SHOW CREATE FUNCTION your_func_name，确认返回的
body内容与你提交的一致（注意换行和空格可能被 MySQL 自动规范化） 实际运行：
SELECT your_func_name(...)，并用已知输入/输出组合验证逻辑，避免因缓存或客户端预编译导致误判
特别注意：如果函数被存储过程或其他函数调用，那些调用者不会自动重编译，它们仍按首次加载时的函数签名和逻辑执行——除非显式执行
FLUSH PROCEDURE CACHE（MySQL 8.0.22+ 支持）或重启连接。
函数修改引发的权限与复制问题
修改函数需要
ALTER ROUTINE权限，但很多线上账号只给了
EXECUTE，
DROP会失败。此时不能靠“绕过 DROP”，必须申请对应权限。
在主从架构下，
DROP FUNCTION和
CREATE FUNCTION都会写入 binlog，但如果从库开启了
log_bin_trust_function_creators=OFF（默认值），且函数不是
DETERMINISTIC或未声明
READS SQL DATA等特性，从库会拒绝执行，导致复制中断，报错
ERROR 1418 (HY000)。
修复方式只有两个：要么在从库临时设
SET GLOBAL log_bin_trust_function_creators = 1（不推荐长期开启），要么在创建时补全特性声明，例如：
CREATE FUNCTION my_add(a INT, b INT) RETURNS INT DETERMINISTIC READS SQL DATA BEGIN RETURN a + b; END
函数体越复杂，越容易漏掉这些修饰符——而一旦漏掉，在 binlog 复制链路上就埋了雷。
