触发器迁移出问题主因是“方言”和“身份规则”绑定过死；mysqldump默认跳过触发器（--skip-triggers启用），需显式加--triggers导出并验证create trigger存在，sql server语法需逐项替换，definer必须精确匹配或统一替换为current_user，嵌套对象definer须逐层检查。
触发器在迁移中出问题，不是因为逻辑写得不对，而是它把数据库的“方言”和“身份规则”焊死在了代码里——一换库就崩。
mysqldump 默认不导触发器，你以为导了其实没导
MySQL 5.7+ 版本默认启用 --skip-triggers，哪怕你什么参数都没加，dump 文件里也不会出现 CREATE TRIGGER。结果就是导入后触发器彻底消失，业务逻辑直接断档。
- 导出时必须显式加
--triggers：例如mysqldump --triggers -u root -p mydb > backup.sql - 导出后立刻验证：
grep -n "CREATE TRIGGER" backup.sql，确认语句真实存在 -
--all-databases不等于包含触发器，它照样受--skip-triggers影响
SQL Server 触发器迁到国产库，TOP/GETDATE/TRYCATCH 全报错
SQL Server 的 TOP 1、GETDATE()、ISNULL()、TRY...CATCH 在 PostgreSQL 或 MySQL 中根本不可执行。金仓等国产库虽支持 sql_compatibility = 'SQLSERVER'，但仅限基础语法；一旦触发器里用了游标、临时表 #temp 或 @@ERROR，照样编译失败。
- 先关兼容模式跑一遍：
SET sql_compatibility = 'STRICT';，暴露所有隐性不兼容点 - 逐个替换函数：
GETDATE()→CURRENT_TIMESTAMP，ISNULL(a,b)→COALESCE(a,b) -
TRY...CATCH必须拆：PostgreSQL 用EXCEPTION WHEN OTHERS THEN，MySQL 8.0+ 不支持原生TRY CATCH，建议改用应用层捕获 - 避免
SELECT TOP N：改用LIMIT N（PostgreSQL/MySQL）或子查询 +ROWNUM（Oracle 兼容路径）
导入时报 ERROR 1359 或 ERROR 1449，不是语法错而是身份崩了
ERROR 1359 (HY000): Trigger already exists 是目标库已有同名触发器；ERROR 1449 (HY000): The user specified as a definer ('xxx'@'%') does not exist 是源库的 DEFINER 用户在新库不存在——这两类错误会直接中断整个导入流程。
- 导入前清空目标库触发器：
SELECT CONCAT('DROP TRIGGER ', TRIGGER_NAME, ';') FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = 'mydb';，生成并执行结果 - 别用
DROP DATABASE后重建：某些触发器绑定在系统表或跨库对象上，删库不等于清干净 - 手动替换
DEFINER：sed -i "s/DEFINER=`.*`@`.*/DEFINER=CURRENT_USER/g" backup.sql，注意CURRENT_USER必须有权限 - MySQL 不支持
CREATE OR REPLACE TRIGGER，脚本里必须保证“先删后建”的顺序
嵌套调用的 DEFINER 容易被忽略，改一个不等于全通
触发器里如果调用了存储过程，那个过程也有自己的 DEFINER；而过程里再调用函数，函数还有 DEFINER。只要其中一层失效，整条链就执行不了。
- 查真实定义：
SHOW CREATE TRIGGER trigger_name;，看整行DEFINER=，包括反引号和主机部分 - 查用户是否存在：
SELECT User, Host FROM mysql.user WHERE User = 'app_user';，结果必须精确匹配（含 Host） - 别用
CREATE USER IF NOT EXISTS硬补——主机名对不上照样失败 - MySQL 8.0+ 若触发器读
@@max_connections等系统变量，定义者还必须有SYSTEM_VARIABLES_ADMIN权限
真正难处理的不是单个触发器语法，而是它像一根线，串起了用户权限、函数行为、嵌套对象定义者、甚至系统变量访问控制——迁移时漏掉任意一环，都可能让业务在某个并发高峰突然静默失败。
