数据库迁移复制这件事说难不难说简单嘛……坑也不少。本文手把手教你用 DBeaver 完成 MySQL 数据库的导出与导入并附赠两个亲测翻车的排坑指南。看完这篇至少能少踩两个坑少掉两根头发。一、导出数据库1. 右键起手打开导出工具在目标 database 上右键 → Tools → Dump database弹出配置窗口后有两件事必须做选择 Local Client没有它导出按钮就是个摆设确认要导出的 database然后点 Next2. 配置 Local Client首次使用必看DBeaver 的导出/导入底层调用的是mysqldump/mysql命令行工具所以你本地得有 MySQL Client。如果本地已安装过DBeaver 会自动识别并填充路径点开确认一下路径是否正确即可。如果没有安装按以下步骤操作Mac 安装方式# 安装 mysql 客户端只要客户端不装 server轻量省心brewinstallmysql-client# 添加到 PATHechoexport PATH/opt/homebrew/opt/mysql-client/bin:$PATH~/.zshrcsource~/.zshrc安装完成后回到 DBeaver点击Local Client → Browse点击Add Home选择本地 MySQL Client 的安装目录3. 确认导出路径开始导出确认输出文件路径点击 Start 即可导出完成后去对应文件夹确认.sql文件是否已生成。到这一步恭喜你——数据已经安全打包带走了 二、导入数据库1. 在目标实例创建新的 database创建一个新的 database比如myapp2. 右键恢复选中刚创建的 database右键 → Tools → Restore database3. 选择 SQL 备份文件在弹出窗口中选择之前导出的.sql文件4. 确认并执行导入点击 Start等待导入完成导入完成收工三、踩坑实录别问我怎么知道的正常流程走完你可能觉得就这——别急精彩的在后面。以下两个坑我替你先踩了。1. 坑一localhost 导致连接失败1.1 问题现象执行导入/导出时DBeaver 直接报错提示找不到 socket 文件ERROR 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock (2)1.2 报错日志mysql -u root --hostlocalhost --port3307 myapp Task MySQL restore started at Sat Mar 07 17:45:23 CST 2026 ERROR 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock (2) Task MySQL restore finished at Sat Mar 07 17:45:23 CST 20261.3 原因分析这是 MySQL 客户端的一个经典潜规则当--hostlocalhost时MySQL 客户端会强制使用 Unix Socket连接完全忽略你指定的--port也就是说你以为自己在连localhost:3307实际上客户端在找/tmp/mysql.sock这个文件。而如果你的 MySQL 跑在 Docker 里Mac 本地压根没有这个 socket 文件——翻车就是这么朴实无华。连接方式实际行为--hostlocalhost走 Unix Socket忽略 port--host127.0.0.1走 TCP/IP使用 port1.4 解决方案在 DBeaver 的连接配置中把 Server Host 从localhost改为127.0.0.1一字之差天壤之别。localhostvs127.0.0.1这大概是 MySQL 最经典的等价但不等价问题了。2. 坑二GTID 冲突导致第二个库导入失败2.1 问题现象导入第一个数据库一切正常导入第二个数据库时直接报错。2.2 报错日志mysql -u root --host127.0.0.1 --port3307 mydata Task MySQL restore started at Sat Mar 07 12:21:01 CST 2026 ERROR 3546 (HY000) at line 24: GLOBAL.GTID_PURGED cannot be changed: the added gtid set must not overlap with GLOBAL.GTID_EXECUTED2.3 原因分析问题出在mysqldump导出的 SQL 文件中会自动包含这样一行SETGLOBAL.GTID_PURGEDxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:1-100;当你有多个数据库需要导入时第一个库导入成功后GTID 信息已经写入目标实例的GLOBAL.GTID_EXECUTED。导入第二个库时SQL 文件里的GTID_PURGED与已有的GTID_EXECUTED产生了重叠冲突MySQL 出于数据一致性保护直接拒绝执行。简单来说就是MySQL 觉得这些事务我已经执行过了你别再给我塞一遍。2.4 解决方案方案一推荐导出时关闭 GTID如果你不需要主从复制开发、测试、迁移场景基本都不需要在导出时加上参数--set-gtid-purgedOFF在 DBeaver 的导出配置中可以在 Extra command args 里填入这个参数这样导出的 SQL 文件就不会包含SET GLOBAL.GTID_PURGED...导入时自然不会冲突。方案二导入前重置目标库的 GTID⚠️警告此操作会清除目标实例的 GTID 历史和 binlog仅适用于本地开发/测试环境生产环境请绕行-- 重置 GTID_EXECUTED需要 SUPER 权限RESET MASTER;-- 然后再执行导入RESET MASTER会清空 binlog 并将 GTID 集合置空这样后续导入就不会产生冲突。适合本地独立开发库无主从关系的场景。四、总结步骤关键操作注意事项导出右键 → Dump database需配置 Local Client建议加--set-gtid-purgedOFF导入右键 → Restore database先建好目标 database避坑连接地址用127.0.0.1别用localhostDocker 场景必翻车避坑多库导入关闭 GTID否则第二个库开始就会报错整个流程其实不复杂但localhost和 GTID 这两个坑属于不踩不知道一踩跳三跳的类型。希望这篇文章能帮你平稳落地少走弯路。如果这篇文章帮你省下了排查时间欢迎点赞收藏毕竟——你省下的时间够多写好几个 bug 了