一、问题背景

一般从 MySQL 迁移到 DM 数据库时，由于 MySQL 字符串的长度是以字符为单位，导致迁移过程中有可能遇到报错：超出定义长度。

在 DM8 的早期阶段，针对从 MySQL 迁移至 DM 的场景，由于当时 DM 尚未原生支持变长字符类型（如 VARCHAR (N CHAR)）的数据存储需求，故引入了 LENGTH_IN_CHAR 参数作为临时解决方案。旨在兼容并处理数据字符串截断的特定情境，确保迁移过程中的数据完整性。

随着项目应用的深入及服务团队的持续反馈，LENGTH_IN_CHAR 参数的启用被发现与多种兼容性问题相关联，核心问题总结如下：

1. LIKE 查询异常
   • 当数据库初始化配置为使用 UTF-8 字符集且不区分大小写，并激活 LENGTH_IN_CHAR 参数时，用户在执行 SELECT 语句采用 LIKE 模式匹配查询字符串时，曾遇到数据检索不准确的问题。
   • 此问题已在 DM8 的 8.1.2.135 版本中得到修复。
2. DBLINK 查询字符集转换错误
   • 在相似的配置环境下（UTF-8 字符集，不区分大小写，启用 LENGTH_IN_CHAR ），通过数据库链接（DBLINK）执行 SELECT 查询时，该参数导致内部字符集转换过程发生异常，引发了字符集截断错误。
   • 此技术障碍亦已在 DM8 的 8.1.1.117 版本中获得解决。
3. 存储差异性问题
   • 若数据库实例配置启用了 LENGTH_IN_CHAR 参数，且字段定义采用 VARCHAR (10)，不同字符集的采用将直接影响到实际可存储的数据量。
   • 这进一步凸显了该参数对数据存储一致性可能产生的不利影响，具体表现依字符编码而异。

综上所述，鉴于 LENGTH_IN_CHAR 参数引发的多方面兼容性和一致性问题，结合已有的版本更新修复情况，其停用被视为提升系统稳定性和兼容性的必要举措，并且在 8.1.3.167 版本正式废弃。

本文就是介绍目前新版 DM 数据库 MySQL 利用 DTS 迁移到 DM 数据库避免超出定义长度问题的方法。

二、DTS 迁移 MySQL

2.1 设置数据类型映射

1. 添加映射
2. 配置：源数据类型名 - VARCHAR，目的数据类型名 - VARCHAR，强制为字符存储选择 - 是
3. 保存

2.2 迁移过程

源端数据库

目的端数据库

迁移选项※

取消单选框，不使用默认数据类型映射关系，便能调用到我们所配置的数据类型映射。

指定模式

指定对象

审阅迁移任务

点击 “完成”，进行迁移，即可完成数据类型的映射。