mysqldump默认不导出存储过程、函数和触发器，需显式添加--routines和--triggers参数；恢复时需确保用户具备create routine和trigger权限，并注意definer及字符集兼容性。
mysqldump 默认不导出存储过程和函数
用 mysqldump 备份时，即使加了 --all-databases 或指定了库名，ROUTINE（即存储过程、函数）和 TRIGGER 默认不会被包含——除非显式启用对应选项。这是最常导致“恢复后触发器/存储过程消失”的根本原因。
检查备份文件是否含 CREATE PROCEDURE 或 CREATE TRIGGER 语句：如果没看到，说明导出时漏了参数。
- 导出必须加
--routines（等价于--triggers --routines，但注意它不含 triggers） - 导出必须加
--triggers（单独生效，只导触发器） - 若需完整导出，推荐组合使用：
mysqldump --routines --triggers --databases db_name > backup.sql -
--routines还会导出函数（FUNCTION），但不会导事件（EVENT），如需事件要额外加--events
恢复时权限不足会导致 ROUTINE 创建失败
导入含 CREATE PROCEDURE 或 CREATE TRIGGER 的 SQL 时，MySQL 会校验当前用户是否有 CREATE ROUTINE 和 TRIGGER 权限。即使你有 GRANT ALL ON *.*，也可能因 sql_mode 中含 NO_AUTO_CREATE_USER 或账户未显式授权而静默跳过创建。
- 恢复前先确认用户权限：
SHOW GRANTS FOR CURRENT_USER;，确保输出含CREATE ROUTINE和TRIGGER - 若权限缺失，用高权限账号执行：
GRANT CREATE ROUTINE, TRIGGER ON `db_name`.* TO 'user'@'%'; FLUSH PRIVILEGES; - 某些 MySQL 5.7+ 版本在导入时若遇到权限不足，不会报错，而是跳过相关语句——检查日志或手动 grep
CREATE PROCEDURE执行结果可验证是否真被跳过
字符集与 DEFINER 问题引发恢复失败或功能异常
备份文件中的 CREATE PROCEDURE 或 CREATE TRIGGER 语句通常带 DEFINER=`user`@`host`。若目标环境不存在该用户，或字符集不匹配（如备份用 utf8mb4，目标库用 latin1），可能导致语法解析失败或后续调用报错。
- 导入前可用
sed -i 's/DEFINER=`[^`]*`@`[^`]*`//g' backup.sql去掉 DEFINER（MySQL 会自动设为当前用户） - 确保目标库默认字符集与备份一致，尤其注意
character_set_database和连接层的character_set_client；否则中文注释或参数可能乱码，导致DELIMITER解析错位 - 若过程体中用了
DELIMITER $$，而导入时客户端未识别该分隔符（如用mysql -e "source backup.sql"），建议改用mysql db_name 方式执行
验证触发器和存储过程是否真正恢复成功
仅看导入命令无报错不等于对象已就位。MySQL 不会在导入过程中主动提示 “已创建 3 个 trigger”，必须手动验证。
- 查触发器：
SELECT TRIGGER_NAME, EVENT_OBJECT_TABLE FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = 'db_name'; - 查存储过程：
SELECT ROUTINE_NAME, ROUTINE_TYPE FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = 'db_name'; - 注意：触发器属于表级对象，
information_schema.TRIGGERS是唯一可靠来源；而SHOW PROCEDURE STATUS可能因权限或缓存显示不全 - 若发现数量对不上，优先检查备份文件里对应语句是否被截断（常见于大过程体未正确处理
DELIMITER）
恢复过程里最容易被忽略的，是 DEFINER 用户不存在 + 权限未显式授予 + 导入方式不支持自定义 DELIMITER 这三者叠加——它们不会直接报错，但会让对象“看似恢复成功，实则从未落地”。
