mysqldump默认不备份触发器和事件，必须显式添加--triggers和--events参数；缺一不可，且需对应权限（TRIGGER、EVENT），否则静默跳过，导入时因DEFINER缺失或权限不足易失败。
MySQL 的 mysqldump 默认不备份触发器和事件，除非显式启用对应选项——这是最常被忽略的配置点。
mysqldump 备份触发器必须加 --triggers
触发器（TRIGGER）不会随表结构自动导出。即使你用了 mysqldump db_name table_name，只要没加 --triggers，生成的 SQL 里就只有 CREATE TABLE，没有 CREATE TRIGGER。
- 正确命令：
mysqldump --triggers --no-create-info --skip-data mydb > triggers.sql（仅导出触发器） - 若要全库含触发器：
mysqldump --triggers mydb > full_with_triggers.sql - 注意：
--triggers在 MySQL 5.6+ 默认开启，但 5.5 及更早版本默认关闭；生产环境别依赖默认值 - 如果导出后发现
CREATE TRIGGER缺失，先检查 MySQL 版本并确认该参数是否生效
事件（EVENT）需要单独指定 --events
事件调度器（EVENT Scheduler）完全独立于表和触发器，--triggers 对它无效。不加 --events，哪怕启用了调度器、事件存在且启用，dump 文件里也绝不会出现 CREATE EVENT 语句。
- 导出事件必须显式加：
mysqldump --events mydb > events.sql - 若同时要触发器 + 事件：
mysqldump --triggers --events mydb > backup.sql - 注意：目标库恢复前需确保
event_scheduler=ON（可通过SET GLOBAL event_scheduler = ON;启用） - 事件定义中包含
ON SCHEDULE和ENABLE/DISABLE状态，--events会完整保留，但恢复后是否自动运行取决于全局变量和权限
权限不足会导致触发器/事件被静默跳过
即使加了 --triggers 或 --events，如果连接用户缺少 TRIGGER 或 EVENT 权限，mysqldump 不报错，只是跳过对应部分——文件里既无提示也无警告，极易误判备份完整。
- 验证权限：
SHOW GRANTS FOR CURRENT_USER;，确认含GRANT TRIGGER ON `db`.* TO ...和GRANT EVENT ON `db`.* TO ... - 最小权限组合：
SELECT, LOCK TABLES, SHOW VIEW, TRIGGER, EVENT（备份时必需） - 使用
--single-transaction时，TRIGGER权限仍不可省；它不靠事务保证，而是靠元数据读取权限
恢复时触发器和事件可能因 DEFINER 失效
导出的 CREATE TRIGGER 和 CREATE EVENT 默认带 DEFINER=`user`@`host`。若目标库不存在该用户，或用户无足够权限，执行会失败（错误如：ERROR 1449 (HY000): The user specified as a definer does not exist）。
- 安全做法：备份时加
--skip-definer，让 mysqldump 生成不带 DEFINER 的语句（MySQL 5.7.8+ 支持） - 兼容旧版方案：用 sed 预处理 dump 文件：
sed 's/DEFINER=[^*]*\*/\*/g' backup.sql > clean.sql - 注意：
--skip-definer不影响存储过程/函数，只作用于 trigger/event/view；但它会让恢复后的对象以当前用户为 DEFINER，需确认其权限是否足够
真正麻烦的不是怎么加参数，而是备份后从不验证——拿 grep "CREATE TRIGGER\|CREATE EVENT" backup.sql 扫一眼，比等恢复失败再排查快十倍。
