一、问题背景

最近经常看到达梦数据库用户苦恼的一个疑问：为什么新版达梦数据库找不到参数 LENGTH_IN_CHAR？

以下本文就来详细介绍一下这个参数的来龙去脉。

二、关于现状

这个参数一直是非推荐参数，并且于 8.1.3.167 版本正式废弃。

三、关于参数停用的原因分析

（1）设计哲学与历史背景

达梦数据库（DM）在架构设计上遵循了与 Oracle 数据库的一致性原则，采用字节作为数据存储的基本计量单位。
在 DM8 的早期阶段，针对从 MySQL 迁移至 DM 的场景，由于当时 DM 尚未原生支持变长字符类型【如 VARCHAR (N CHAR)】的数据存储需求，故引入了 LENGTH_IN_CHAR 参数作为临时解决方案。
旨在兼容并处理数据字符串截断的特定情境，确保迁移过程中的数据完整性。

（2）兼容性挑战与问题概述

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

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

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

四、关于参数停用后的疑问

4.1 MySQL 数据库的数据如何迁移

两种方案：

• 可通过 DTS 迁移工具将 MySQL 的 VARCHAR 类型自行转为 VARCHAR N CHAR 类型。参考文章：MySQL 数据库迁移到达梦数据库超出定义长度问题
• 迁移前手动扩充下 DM 侧表的字段长度。

4.2 已有版本升级或数据导入新版本如何处理

如需要版本升级（使用旧版本已经稳定的系统不建议再升级）：建议使用 DTS 迁移到新实例中，其中手动设置类型映射：

• 将 CHAR 映射为 VARCHAR (以字符存储）
• VARCHAR 映射为 VARCHAR (以字符存储）
• VARCHAR2 映射为 VARCHAR2 (以字符存储）

逻辑数据导入：

建议先导入数据结构后，使用 DTS 工具，对原有的 CHAR/VARCHAR/VARCHAR2 类型进行数据映射，改为按字符存储（其中 CHAR 改为 VARCHAR 后按字符存储，或直接扩展字段长度）

目前版本新增了逻辑导入参数 IGNORE_INIT_PARA。可选择忽略某些初始化参数。