mysql函数和触发器如何迁移_mysql数据迁移方案

mysql函数触发器迁移需处理definer权限、sql security、binlog信任设置、跨库依赖、大小写敏感、5.7到8.0语法变更（如not deterministic限制）、类型校验增强及隐式转换风险，须分验证/灰度/切流三步实施。

直接导出再导入函数，常遇到 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 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

真正麻烦的从来不是导出命令怎么写，而是函数里藏着的隐式类型转换、触发器里耦合的业务状态判断——这些不会报错，但会让数据慢慢歪掉。