MySQL Workbench迁移向导：批量数据传输阶段报错求解决方案

我之前也在MySQL Workbench的批量数据迁移阶段踩过不少坑，给你整理几个最常见的排查和解决方向：

• 先确认连接稳定性
  有时候迁移中途断连会触发模糊的错误提示。你可以先在Workbench里分别测试源库和目标库的连接（点"Test Connection"），如果是远程数据库，检查下网络是否稳定、防火墙/安全组有没有放开MySQL端口（默认3306），避免迁移过程中被掐断连接。

• 排查数据类型兼容性问题
  这是批量迁移报错的重灾区！比如源库的TEXT字段长度超过目标库VARCHAR的限制、源库的ENUM值在目标库未定义、日期类型精度不匹配（比如源库是datetime(6)而目标库只支持datetime）。
  解决办法：在迁移向导的「Select Tables」阶段，点开每个表的「Column Mapping」仔细核对，手动调整不兼容的类型；或者提前在目标库建好与源库完全匹配的表结构，再进行迁移。

• 处理主键/唯一约束冲突
  如果目标库已经存在数据，迁移时主键或唯一键重复就会直接报错。你可以在迁移的「Advanced Options」里找一下：

  • 勾选「Overwrite existing tables」或「Truncate tables before import」，先清空目标表再迁移；
  • 如果不想清空数据，就修改迁移规则，设置为跳过重复数据或更新现有数据。

• 调整批量插入参数
  Workbench默认的批量插入大小可能过大，导致超时或内存不足。在「Bulk Data Transfer」步骤里，找到「Batch Size」（批量大小），把数值调小（比如从1000改成100），同时适当延长「Timeout」（超时时间）设置，给数据传输更多缓冲空间。

• 查看详细错误日志定位根源
  别只看弹窗的简短错误！迁移窗口底部有个「Log」标签页，里面会记录具体的错误细节——比如哪张表、哪一行数据出了问题，甚至会提示字段长度超限、约束冲突等具体原因。根据日志去针对性修复，比盲目排查高效太多。

• 检查数据库账号权限
  确保源库账号有完整的SELECT权限，目标库账号拥有CREATE、INSERT、ALTER、INDEX这些必要权限。有时候迁移到中途因为权限不足，创建索引或插入数据就会失败。

内容的提问来源于stack exchange，提问作者Lukasz Koziara