mysql函数触发器迁移需处理definer权限、sql security、binlog信任设置、跨库依赖、大小写敏感、5.7到8.0语法变更（如not deterministic限制）、类型校验增强及隐式转换风险，须分验证/灰度/切流三步实施。
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
真正麻烦的从来不是导出命令怎么写，而是函数里藏着的隐式类型转换、触发器里耦合的业务状态判断——这些不会报错，但会让数据慢慢歪掉。
