17370845950

修改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，而非客户端连接设置。改库字符集后，旧函数不会自动更新，必须重建。