导出SQL脚本必须同时包含建表语句和插入数据，并显式指定UTF-8编码及--default-character-set=utf8mb4参数，否则导入易报错或乱码；DBeaver中需勾选Export DDL与Export data，禁用外键检查并校验目标库字符集。
导出的 SQL 脚本必须包含建表语句 + 插入数据 + 兼容目标库字符集，否则导入时大概率报错或乱码。
导出时必须勾选“导出数据”和“导出 DDL”
只选“导出 DDL”会生成空表结构，没数据；只选“导出数据”则没有 CREATE TABLE 语句，导入到空库会失败。DBeaver 默认两者都勾选，但容易被手动取消——尤其在多表导出时误操作。
- 右键数据库 →
Tools→Dump database - 在“Objects”页确认所有要迁移的表已勾选（可 Ctrl+多选）
- 在“Options”页检查：
Export DDL和Export data都为启用状态 - 若目标库已有同名表且需覆盖，额外勾选
Add DROP statements和Disable foreign key checks
字符集不匹配是导入失败最常见原因
MySQL 客户端默认用 gbk 连接，而导出脚本通常是 UTF8MB4 编码。导入时若不显式指定，mysqldump 会按客户端编码解析 SQL，导致中文变问号或报错 ERROR 1300 (HY000): Invalid utf8mb4 character string。
- 导出时，在“Output settings”页将
Encoding明确设为UTF-8 - 导入时，DBeaver 底层调用
mysql命令，需在“Restore database”窗口的Advanced标签页中添加参数：--default-character-set=utf8mb4 - 如果导入仍失败，检查目标库的
character_set_database是否为utf8mb4（执行SHOW VARIABLES LIKE 'character_set_database';）
“执行脚本”和“恢复数据库”两种方式的区别
很多人混淆这两个入口，结果导入失败却找不到原因。
-
Tools → Restore database：走mysql命令行工具，支持事务、进度反馈、错误定位，适合整库/大文件导入，**必须配置 Local Client** -
Tools → Execute script：走 JDBC 连接直接执行 SQL，不依赖本地 MySQL 客户端，但对超大文件易内存溢出、无进度条、报错信息模糊，适合小脚本或含CREATE DATABASE的初始化脚本 - 如果脚本里有
CREATE DATABASE myapp;，优先用Execute script，并确保连接的是 MySQL 实例根节点（不是某个具体库）
导入后数据不一致？重点检查外键和自增 ID
即使导入成功，也可能出现主键冲突、关联数据丢失、时间字段异常等问题，根源常在导出时未处理约束与序列。
- 导出前确认是否勾选
Disable foreign key checks（否则插入顺序错乱会失败） - 若表有
AUTO_INCREMENT，导出脚本默认带INSERT INTO ... VALUES (1, ...)，导入到已有数据的表会冲突；此时应勾选Extended insert并配合SET FOREIGN_KEY_CHECKS=0;和SET SQL_MODE='NO_AUTO_VALUE_ON_ZERO'; - 导入后立即执行
SELECT COUNT(*)对比源库，再查几条关键记录的id和中文字段是否完整
真正麻烦的不是导出动作本身，而是导出参数和导入上下文的隐式耦合——比如导出时用了 UTF-8 编码，但导入时没传 --default-character-set=utf8mb4，错误日志里只会显示“process failed (exit code = 1)”，得翻 DBeaver 日志才能看到真实报错。
