修改 MySQL 自定义函数后需刷新权限缓存并重启连接，因函数元数据被缓存；5.7 与 8.0 在 DETERMINISTIC 声明、变量声明、字符串拼接等方面语法兼容性差；函数以 definer 权限运行，须确保其具备对应表和函数的权限；跨 schema 调用需全限定名；字符集不一致易致乱码，应显式声明 charset 与 collate。
修改 MySQL 自定义函数后必须刷新权限缓存
MySQL 不会自动重载已存在的函数定义，即使你用 CREATE OR REPLACE FUNCTION 或先 DROP FUNCTION 再 CREATE FUNCTION，调用时仍可能执行旧逻辑。根本原因是函数元数据被缓存，且部分版本（尤其是 5.7 及更早）不触发自动清理。
- 执行
FLUSH FUNCTIONS（MySQL 8.0.23+ 才支持）——但多数生产环境还没升级到这个版本 - 更通用的做法是：重启 MySQL 服务，或至少执行
FLUSH PRIVILEGES+ 重启客户端连接（因为函数定义在 session 层也有缓存） - 验证是否生效：用
SELECT name, type, sql_data_access FROM mysql.proc WHERE name = 'your_func_name';查看modified时间戳和sql_data_access是否更新
MySQL 5.7 和 8.0 函数语法兼容性差异明显
MySQL 8.0 引入了严格 SQL 模式默认开启、不可为空参数强制声明、以及对 DETERMINISTIC / NO SQL 等特性更严格的校验，而 5.7 宽松得多。直接迁移函数代码常报错。
-
CREATE FUNCTION中若省略DETERMINISTIC、NO SQL或READS SQL DATA，8.0 会拒绝创建（报错ERROR 1418），5.7 则默认为DETERMINISTIC - 8.0 要求函数体中所有变量必须显式
DECLARE，5.7 允许隐式创建（但行为不可靠） - 字符串拼接：5.7 支持
CONCAT('a', col)即使col为NULL，结果为NULL；8.0 在 strict mode 下可能因 隐式类型转换 失败
CREATE FUNCTION safe_concat(a VARCHAR(100), b VARCHAR(100)) RETURNS VARCHAR(200) DETERMINISTIC READS SQL DATA BEGIN RETURN CONCAT(IFNULL(a, ''), IFNULL(b,'')); END;函数内调用其他函数或表时的权限与上下文陷阱
自定义函数运行在 definer 权限下，不是调用者权限。如果函数里用了 SELECT …… FROM some_table 或调用了另一个函数，而 definer 用户没有对应权限，就会静默失败或报 ERROR 1449（The user specified as a definer does not exist）。
- 检查当前 definer：
SELECT definer FROM mysql.proc WHERE name = 'your_func_name'; - 确保该用户存在且拥有
EXECUTE权限（对函数本身）和SELECT权限（对函数内访问的表） - 避免在函数中写
INSERT/UPDATE—— MySQL 限制函数不能修改数据（除非用存储过程替代） - 跨 schema 调用函数时，务必用
schema_name.func_name()全限定名，否则 5.7 可能找错，8.0 默认只查当前 schema
字符集与排序规则不一致导致函数返回乱码或比较异常
函数参数、返回值、内部变量、甚至临时表字段的字符集若与客户端或表不一致，会导致 CONVERT 隐式失败、LIKE 匹配失效、或 LENGTH() 与 CHAR_LENGTH() 结果偏差。
- 显式声明函数参数和返回值的字符集：
CREATE FUNCTION f(s TEXT CHARSET utf8mb4) RETURNS TEXT CHARSET utf8mb4 - 内部字符串操作前统一转码：
CONVERT(s USING utf8mb4) - 特别注意
COLLATE：若函数用于 ORDER BY 或 GROUP BY 场景，返回值最好指定COLLATE utf8mb4_0900_as_cs（8.0）或utf8mb4_unicode_ci（5.7）
最易被忽略的是：函数创建时的默认字符集取决于 character_set_database，而非客户端连接设置。改库字符集后，旧函数不会自动更新，必须重建。
