mysql不支持alter function修改函数体，必须通过drop+create实现变更；安全重建需采用版本化命名、原子切换和四点验证（确定性声明、返回类型、主从同步、结果一致性），并显式指定definer以避免权限错误。
不能直接修改 MySQL 存储函数的函数体，必须通过「删除 + 重建」实现逻辑变更；但只要操作得当，全程可做到零业务中断。
为什么 ALTER FUNCTION 不能改函数体
MySQL 的 ALTER FUNCTION 仅支持修改函数的特性（如 SQL SECURITY、COMMENT、READS SQL DATA 等），不接受 AS BEGIN ... END 或函数体内容。试图用它替换逻辑会报错：ERROR 1305 (42000): FUNCTION xxx does not exist（因语法不匹配导致解析失败）。
真正能更新函数定义的唯一合法路径是先 DROP FUNCTION，再 CREATE FUNCTION。
安全重建三步法：原子切换
核心思路是让新旧函数共存一小段时间，并控制调用方只看到新版本——不是靠“改”，而是靠“换”。
- 给新函数起一个带版本后缀的临时名，比如原函数叫
calc_discount，新建为calc_discount_v2 - 在应用层或视图/存储过程中，把所有对
calc_discount的引用，批量替换成calc_discount_v2（确保所有调用点统一） - 确认无任何地方还在调用旧函数后，再执行
DROP FUNCTION calc_discount，最后RENAME FUNCTION calc_discount_v2 TO calc_discount（MySQL 8.0.30+ 支持RENAME FUNCTION；低于该版本需用DROP+CREATE，但务必在低峰期并加锁表验证）
上线前必须验证的四个点
哪怕函数体只改了一行，漏掉任一验证都可能引发隐性故障：
- 检查
DETERMINISTIC/NOT DETERMINISTIC声明是否与实际行为一致——若函数实际依赖NOW()或会话变量却声明为DETERMINISTIC，会导致主从复制不一致或查询缓存误用 - 确认返回值类型未变（如原返回
DECIMAL(10,2)，别改成FLOAT），否则调用它的 SQL 可能因隐式转换出错或精度丢失 - 在从库上执行
SHOW CREATE FUNCTION，验证函数定义已同步（尤其使用异步复制时，主库建完不等于从库立刻可用） - 用
SELECT calc_discount(...)和SELECT calc_discount_v2(...)对比相同输入，检查结果是否完全一致（注意 NULL 处理、空字符串、边界值）
最易被忽略的坑：权限与 DEFINER
重建后函数默认以当前用户为 DEFINER，如果原函数是 DEFINER='admin'@'%'，而你用普通账号重建，会导致调用时报 ERROR 1449 (HY000): The user specified as a definer ('admin'@'%') does not exist。
正确做法是在 CREATE FUNCTION 语句开头显式指定：CREATE DEFINER='admin'@'%' FUNCTION calc_discount_v2(...)...。同时确认该账号在目标实例上真实存在且有足够权限——这一步在跨环境迁移或 RDS 实例中特别容易翻车。
