mysqldump导出触发器必须显式加--triggers参数，因MySQL 5.7+默认跳过触发器导出，否则dump文件无CREATE TRIGGER语句，导入后业务逻辑断档；需验证语句存在、清理目标库同名触发器、替换DEFINER、确保依赖对象就位。
mysqldump 导出触发器必须加 --triggers
MySQL 5.7+ 默认跳过触发器导出，哪怕你写了 mysqldump -u root -p mydb，生成的 SQL 文件里也不会有 CREATE TRIGGER 语句——这不是漏参数，是默认行为。结果就是导入后业务逻辑直接断档。
- 显式加上
--triggers：例如mysqldump --triggers -u root -p mydb > backup.sql - 导出后立刻验证：
grep -n "CREATE TRIGGER" backup.sql，确认语句真实存在且数量对得上 -
--all-databases不自动包含触发器，它照样受--skip-triggers影响，别信“全量就安全”
导入前必须先清理目标库同名触发器
MySQL 不支持 CREATE OR REPLACE TRIGGER，脚本里如果先 CREATE TRIGGER 再 DROP，执行到第一行就报 ERROR 1359 (HY000): Trigger already exists)，整个导入中断。
- 导入前执行：
SELECT CONCAT('DROP TRIGGER ', TRIGGER_NAME, ';') FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = 'mydb';，复制结果并执行 - 不要用
DROP DATABASE清库：某些触发器绑定在系统表或跨库对象上，删库不等于清干净 - 避免手动拼写
DROP TRIGGER：表名大小写敏感（Linux），RdRecord和rdrecord是两个对象，拼错就报错
DEFINER 用户不存在导致 ERROR 1449
导出文件里的 DEFINER=`admin`@`10.0.0.%` 在目标库不存在，就会卡在 ERROR 1449 (HY000): The user specified as a definer does not exist，不是语法错，是权限问题。
- 用
sed -i "s/DEFINER=`.*`@`.*/DEFINER=CURRENT_USER/g" backup.sql替换，但要确保CURRENT_USER有TRIGGER权限 - 更稳妥的做法：导入前执行
SET SQL_LOG_BIN = 0;+SET autocommit = 1;，再跑导入，绕过 binlog 权限校验（仅主库有效） - 如果用
mysqlpump（MySQL 5.7+），加--skip-definer --triggers可自动剥离 DEFINER，比 mysqldump 更干净
触发器依赖的表和函数必须提前就位
触发器本身能建成功，不代表它能运行。一旦里面引用了未创建的表、视图、函数或跨库对象，首次触发时才报错，比如 Table 'sys_log.audit_log' doesn't exist 或 Can't find function check_date_valid。
- 先查触发器定义：
SHOW CREATE TRIGGER t_audit_insert;，重点看ACTION_STATEMENT里有没有跨库名（如other_db.log_table）、函数调用、临时表 - 确保基表结构一致：字段名、类型、索引都对得上，特别是
NEW.date引用的字段在目标表是否存在 - 函数必须先于触发器导入：否则
mysqldump --routines --triggers导出的顺序不保证依赖关系，得手动调整 SQL 文件顺序
