MySQL函数修改需先DROP再CREATE，不能用CREATE OR REPLACE；5.7与8.0在原子性、sql_mode、变量声明、语法支持等方面存在关键差异；验证更新须查元数据、定义和实际运行三层面。
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 复制链路上就埋了雷。
