为何IBM DB2会自动将nchar(2)/nvarchar(10)转为char(8)/varchar(40)？

核心类型对应关系 #

针对你需要的 Unicode 支持，MSSQL 的 nchar(n) 和 nvarchar(max) 在 DB2 11.5 中有明确的对应类型，分两种场景：

场景1：使用 DB2 专属 Unicode 类型（GRAPHIC 系列） #

这类类型专为双字节/Unicode 存储设计，不受数据库字符集限制：

• MSSQL nchar(n) → DB2 GRAPHIC(n)：固定长度，每个字符占用2字节，严格对应 nchar 的固定长度 Unicode 存储
• MSSQL nvarchar(max) → DB2 VARGRAPHIC(10485760)：DB2 11.5 中 VARGRAPHIC 的最大长度为 10485760 字节，满足大部分大长度 Unicode 存储需求；如果需要更大容量，可使用 CLOB(2G)（支持最高2GB的 Unicode 字符存储）

场景2：DB2 数据库采用 UTF-8 编码（推荐多语言场景） #

若你的 DB2 数据库编码为 UTF-8（CODEPAGE=1208），直接使用常规字符类型也能完美支持 Unicode：

• MSSQL nchar(n) → DB2 CHAR(n)：此处的 n 指字符数而非字节数，UTF-8 编码下可存储任意 Unicode 字符
• MSSQL nvarchar(max) → DB2 VARCHAR(32672)（适用于较大长度但未超上限的场景）或 CLOB(2G)（超大型数据存储）

关于工具自动映射为 char(8)/varchar(40) 的原因 #

DBeaver 或 DB2 控制台自动生成单字节类型，是因为工具默认采用了 SBCS（单字节字符集）的映射规则，未识别到你需要 Unicode 支持；或者你的 DB2 数据库默认字符集为单字节编码（如 CODEPAGE=819），导致工具优先匹配单字节类型。

实操建议 #

1. 先确认数据库字符集：

   SELECT CODEPAGE FROM SYSIBM.SYSDATABASE;
   

   返回 1208 即为 UTF-8 编码，适合直接用常规字符类型；其他编码建议使用 GRAPHIC 系列类型。

2. 创建表时手动指定目标类型，避免工具自动映射的偏差：
   示例（GRAPHIC 系列）：

   CREATE TABLE user_info (
       user_id GRAPHIC(10),
       user_desc VARGRAPHIC(10485760),
       remark CLOB(2G)
   );
   

   示例（UTF-8 编码下用常规类型）：

   CREATE TABLE user_info (
       user_id CHAR(10),
       user_desc VARCHAR(32672),
       remark CLOB(2G)
   );
   

内容的提问来源于stack exchange，提问作者Bruce.Kwon