触发器选项是什么
mysqldump 默认带 --triggers，把表上的触发器定义一起导出。备份文件里导入顺序由 mysqldump 自己保证：先建表、再插数据、最后创建触发器，这样导入过程中不会因为触发器而被二次加工。需要关闭它的场景也很明确：只搬数据到已有库、或把多份导出文件合并恢复时，重复创建同名触发器会直接报错，此时用 --skip-triggers 只导数据。
基本信息
| 默认行为 | --triggers 开启，触发器随表一起导出 |
|---|---|
| 关闭方式 | --skip-triggers |
| 文件内顺序 | 建表语句、插入数据、再创建触发器（由工具保证） |
| 常见组合 | 补数据时配 --no-create-info 只导数据行 |
| DEFINER | 触发器定义里带执行者账号，恢复端需要同名账号或相应权限 |
典型使用场景
- 完整灾备备份：保持默认选项，恢复到空实例时触发器能一并重建
- 向已有库补数据：目标库触发器已存在，导出时跳过定义避免冲突
- 多文件合并导入：手工拼接多份导出容易打乱顺序，跳过触发器再统一创建更可控
- 跨环境同步：从库已有自己的触发器逻辑，导入时不要覆盖源端定义
- 排障对照：单独导出触发器定义，比对两个环境的差异
场景对比
场景对比
# 完整备份：默认就带触发器，无需额外参数
mysqldump -uroot -p --single-transaction appdb > appdb_full.sql
# 只补数据：不建表、不带触发器，往已有库灌数据
mysqldump -uroot -p --no-create-info --skip-triggers appdb orders > orders_rows.sql
# 单独导出触发器定义（结构+触发器，不带数据）
mysqldump -uroot -p --no-data --routines --triggers appdb > appdb_schema.sql
# 导入前确认目标库已有同名触发器，避免重复创建
mysql -uroot -p appdb -e "SHOW TRIGGERS LIKE 'orders';"选项与场景对照
| 场景 | 推荐参数 | 原因 |
|---|---|---|
| 恢复到空实例 | 默认（含 --triggers） | 触发器需要一并重建 |
| 往已有库补数据 | --no-create-info --skip-triggers | 不重复建表与触发器 |
| 只导出结构 | --no-data --routines --triggers | 取得完整 DDL 便于比对 |
| 多份备份合并 | 各自 --skip-triggers，最后统一创建 | 避免顺序错乱导致重复定义 |
| 跨版本迁移 | 默认，但需先核对 DEFINER | 触发器定义中的账号可能不存在 |
触发器定义里保存了 DEFINER 账号。恢复到账号体系不同的环境时，缺少同名账号且当前用户权限不足会导致创建失败，导入前先确认目标环境账号或按需调整。备份脚本在导入阶段要检查这部分错误输出。
手工把多份导出文件拼接成一个文件最容易出问题：触发器定义散落在不同位置且可能重复，尽量用一次整库导出，或明确按「先结构后数据」的顺序合并。