MySQL 函数迁移时要注意 DEFINER 和 SQL SECURITY
直接导出再导入函数，常遇到
Access denied; you need (at least one of) the SUPER privilege(s)错误，根本原因是
DEFINER用户在目标库不存在，或当前用户没权限模拟该定义者。 导出前先执行
SET GLOBAL log_bin_trust_function_creators = 1;（仅限 MySQL 5.7+，且 binlog 开启时必需） 用
mysqldump --routines --no-create-info --no-data --skip-triggers单独导出函数和存储过程 导入前手动替换导出文件里的
DEFINER=`user`@`host`为
DEFINER=CURRENT_USER或删掉整段（MySQL 8.0+ 支持
ALTER FUNCTION ... SQL SECURITY INVOKER） 若目标库关闭了
log_bin_trust_function_creators，必须由有
SUPER权限的用户执行创建，普通账号无法绕过
触发器迁移失败多半卡在表名大小写和依赖顺序
触发器绑定在具体表上，
mysqldump --triggers默认按库→表顺序导出，但若触发器里引用了其他库的表（比如审计日志写到
sys_log），而该库还没建好，导入就会报
Table 'xxx' doesn't exist。 用
SHOW CREATE TRIGGER `t_name`手动检查每个触发器的
ON表名是否带库前缀；Linux 环境下表名区分大小写，
mytable和
MyTable是两个对象 避免跨库引用：把触发器逻辑改成本库临时表或消息队列，否则迁移时得严格控制导入顺序 如果用
mysqlpump（MySQL 5.7+），加
--skip-definer --triggers可自动剥离
DEFINER，比
mysqldump更干净 触发器中调用函数？确保函数已先于触发器导入，否则
Can't find function报错不提示具体哪个函数
MySQL 5.7 到 8.0 迁移时函数语法兼容性最易踩坑
MySQL 8.0 移除了部分旧语法，比如
CREATE FUNCTION中不能用
NOT DETERMINISTIC+
READS SQL DATA组合声明（会报
ERROR 1418），还强制要求显式指定
SQL SECURITY。 8.0 默认开启
sql_mode=STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION，函数内若用
SELECT ... INTO赋值给未声明变量，会直接报错退出
OLD和
NEW在触发器里仍是只读，但 8.0 对其字段类型校验更严——比如对
NEW.id赋值字符串，即使字段是
VARCHAR，也可能因隐式转换失败 用
information_schema.ROUTINES查函数定义时，
8.0的
ROUTINE_DEFINITION字段是
longtext，可能被截断，建议用
SHOW CREATE FUNCTION替代
生产环境迁移建议分三步走：验证、灰度、切流
函数和触发器不是纯数据，它们嵌在业务逻辑里，一旦出错会影响写入链路，不能只看“能导入”。
先在测试库跑SELECT类函数，确认返回值类型和 NULL 处理一致（比如
IFNULL('', 'N/A') 在 5.7 和 8.0 下对空字符串处理可能不同）
对触发器，重点测边界场景：批量 INSERT ... ON DUPLICATE KEY UPDATE是否触发多次、
DELETE带
WHERE条件时是否漏触发 上线后盯住
performance_schema.events_statements_summary_by_digest，查是否有新出现的
ERROR摘要，特别是
ER_SP_DOES_NOT_EXIST或
ER_BAD_NULL_ERROR
真正麻烦的从来不是导出命令怎么写，而是函数里藏着的隐式类型转换、触发器里耦合的业务状态判断——这些不会报错，但会让数据慢慢歪掉。
