mysqldump 能否直接导出存储过程和触发器？
可以，但默认不导出。
mysqldump默认只导出表结构和数据，存储过程、函数、触发器、事件等「高级对象」需显式启用对应参数，否则迁移后会丢失，且无任何警告。
--routines：导出存储过程和函数（注意：不包含触发器）
--triggers：导出触发器（每个表的触发器会紧随该表建表语句之后）
--events：导出事件调度器中的事件（如需） 必须搭配
--databases或指定库名使用，单独用
--all-databases时
--routines才生效
错误示例：
mysqldump mydb > dump.sql—— 触发器和存储过程全丢。
正确写法：
mysqldump --routines --triggers --databases mydb > dump.sql
导入时提示 ERROR 1418 或 DEFINER 权限失败怎么办？
这是最常见卡点：源库中存储过程/触发器定义了
DEFINER='user@host'，而目标库不存在该用户，或当前登录用户无
SET_USER_ID权限，MySQL 拒绝创建。 临时解决（推荐用于开发/测试环境）：
mysqldump --routines --triggers --databases mydb --skip-definer > dump.sql，跳过 DEFINER 子句，改用当前用户作为 definer 生产环境更稳妥的做法：在目标库提前创建同名用户并授权，或用
CREATE USER 'user'@'host' IDENTIFIED BY 'pwd'; GRANT ...补齐权限 导入时加
--force不解决根本问题，只会跳过报错语句，导致对象缺失
注意：
--skip-definer不影响 SQL SECURITY 定义（如
SQL SECURITY DEFINER），仅移除 DEFINER= 部分。
跨版本迁移（如 MySQL 5.7 → 8.0）要注意什么？
MySQL 8.0 对存储过程语法和权限模型有实质性调整，直接导入可能失败。
8.0 移除了mysql.proc表，改用数据字典表；但
mysqldump --routines生成的仍是兼容语法，通常可导入，不过建议检查 dump 文件中是否有
CREATE PROCEDURE ... CONTAINS SQL等已废弃的特性说明子句 触发器中若引用了被删除的系统变量（如
@@sql_mode在某些上下文中行为变更），运行时才暴露，dump 阶段不报错 强烈建议在目标版本上先用
mysql -u user -p &1 | grep -i "error\|warning"快速扫一遍潜在问题
特别提醒：MySQL 8.0 默认开启
sql_require_primary_key，若触发器内涉及 INSERT INTO 某张无主键的表，即使 dump 成功，后续执行也可能报错。
只想迁移某几个存储过程，不导整个库怎么办？
没有内置命令直接按名称导出单个 routine，但可用元数据查询拼出
CREATE语句：
SELECT CONCAT('CREATE ', type, ' ', db, '.', name, ' ', sql_data_access, ' ', security_type, ' ', definer, ' ', character_set_client, ' ', collation_connection, ' ', database_collation, ' AS\n', body, ';')
FROM mysql.proc
WHERE db = 'mydb' AND name IN ('proc_a', 'proc_b');
注意：
mysql.proc在 MySQL 8.0+ 中已不可见（被数据字典替代），此时应查
information_schema.routines和
information_schema.triggers，但字段名和权限要求不同（需 SELECT 权限且不能是匿名用户）。
更可靠的做法：用客户端工具（如 MySQL Workbench）连接源库，右键 routine → “Copy to Clipboard” → “Create Statement”，手动整理；或写小脚本调用
SHOW CREATE PROCEDURE proc_name逐个获取——它返回两列：
Procedure和
Create Procedure，第二列即完整定义。
触发器同理，用
SHOW CREATE TRIGGER trigger_name，注意它不支持通配符，必须指定具体名。
