MySQL Workbench迁移失败：Amazon MySQL转Docker本地实例遇类型错误

原因分析 #

从报错日志可以确定，问题出在MySQL Workbench反向工程源库的sourcedb.doOverlap函数时，程序尝试将字符串与NoneType值拼接，触发类型错误。常见触发场景包括：

• 该函数的元数据存在缺失（比如无函数注释、参数属性定义不完整），Workbench解析时获取到None值后引发拼接错误；
• 源端Amazon RDS MySQL与本地Docker MySQL的版本差距过大，Workbench对特定版本的函数元数据解析存在兼容性bug；
• 使用的MySQL Workbench版本过旧，存在已知的函数反向工程解析漏洞。

解决方案 #

• 检查并修复函数定义：在源库执行SHOW CREATE FUNCTION sourcedb.doOverlap;查看函数完整定义，确认是否存在语法异常、元数据缺失（如无注释、参数类型定义不规范），必要时补全或调整函数定义。
• 跳过该函数自动迁移：在Workbench的迁移对象选择中排除sourcedb.doOverlap，先完成其他Schema和数据的迁移，之后手动导出该函数的SQL语句，在目标库执行创建。
• 同步MySQL版本：尽量让本地Docker的MySQL版本与Amazon RDS的版本保持一致（或控制在小版本差异范围内），避免版本不兼容导致的解析问题。
• 升级MySQL Workbench：将Workbench更新至最新稳定版，旧版本的反向工程模块可能存在已知的NoneType拼接bug，新版本通常会修复这类问题。
• 排查专属特性依赖：确认该函数是否使用了Amazon RDS专属的函数或语法（如特定存储引擎、RDS独有函数），替换为标准MySQL兼容的语法后再尝试迁移。

内容的提问来源于stack exchange，提问作者Simple Fellow