SQLSTATE 22001对应的错误名称是STRING DATA RIGHT TRUNCATION，也就是字符串数据右截断。直观理解就是：你想把一个长度为100的字符串塞进一个只能容纳50个字符的字段或变量里，DB2直接拒绝并抛出这个错误。在实际项目中它经常出现在INSERT、UPDATE、LOAD导入、存储过程赋值以及程序绑定变量等环节，报错信息里通常会附带SQLCODE为-302（值为参数或变量无效，原因是字符串数据右截断）或者-433（值为参数或变量过长）。要彻底解决它，必须先弄清楚截断发生在哪一层：是字段定义太短，还是宿主变量太短，还是字符集转换导致长度膨胀。
一、22001错误的本质与常见触发场景
DB2的错误体系由SQLCODE和SQLSTATE两部分组成。SQLCODE是具体错误码，比如-302、-433、-4461等；SQLSTATE是五字符的标准状态码，22001专门表示字符数据在右边被截断。之所以强调“右边”，是因为DB2在字符层面是按位置存放的，超长部分必然是从尾部溢出。
这个错误的触发场景主要有以下几类：
- 表字段长度不足：字段定义为VARCHAR(50)，实际写入的字符串长度超过50，INSERT或UPDATE时直接报错。
- 宿主变量或参数标记长度不够：在C、Java、COBOL等程序中绑定的变量长度小于实际传入值长度，比如JDBC中setString之前没有对长度做控制，而数据库端预编译时按较短长度处理。
- LOAD或IMPORT工具导入：源文件中某一行字段超长，导入时默认会报22001，除非指定了modified by truncate的容忍策略。
- <码页转换导致膨胀：数据库码页是GBK而客户端是UTF-8，或反过来，一个汉字在不同码页下占用字节数不同（GBK占2字节，UTF-8占3字节），赋值时字节长度超过目标定义。这是最容易踩坑的一类，因为程序里肉眼数出来的字符个数看起来没超，但按字节算超了。
- CAST或SUBSTR表达式目标长度过短：比如CAST(name AS VARCHAR(10))，而name实际有15个字符。
需要注意的是，DB2中CHAR和VARCHAR的长度语义默认是字节而不是字符（在非 STRING UNITS 数据库中）。定义VARCHAR(10)在GBK码页下可以存5个汉字，在UTF-8码页下只能存3个左右，这是很多从Oracle迁移过来的开发者容易忽视的差异。
二、排查步骤：如何快速定位是哪个字段、哪条SQL出的问题
遇到22001不要盲目改字段长度，先做定位。第一步看应用日志里的完整错误信息，DB2的报错通常会带上token，比如“SQLSTATE=22001, SQLERRMC=MYTABLE.DESCRIPTION”，这个token往往直接指出出问题的字段。如果日志没有保留token，就需要手工排查。
第二步确认字段定义长度，用DESC命令或者查询系统目录表：
-- 查看表结构 DESC TABLE mytable; -- 或者查询系统目录，直接拿到长度和类型 SELECT COLNAME, TYPENAME, LENGTH, STRINGUNITSTYPE FROM SYSCAT.COLUMNS WHERE TABNAME = 'MYTABLE' AND TABSCHEMA = 'MYSCHEMA';
第三步确认实际数据的长度，看看最长的那条记录有多长：
-- 按字节查看最大长度 SELECT MAX(LENGTHB(description)) FROM staging_table; -- 按字符查看最大长度 SELECT MAX(LENGTH(description)) FROM staging_table;
对比LENGTH列的定义值和LENGTHB的实际最大值，如果实际值大于定义值，基本就锁定了问题字段。如果是LOAD导入报错，还可以查看导入生成的异常表或者用db2load查询被拒绝的行，被拒行的具体字段内容会说明截断发生在哪一列。
如果错误来自应用程序而不是SQL脚本，还要检查JDBC连接串的字符集设置以及PreparedStatement的绑定方式。可以用db2pd抓取package cache里真实执行的SQL语句，确认参数值的实际长度：
db2pd -d MYDB -dynamic -statements > dynamic_sql.txt
三、解决方案：根据根因选择不同的修复方式
定位到根因之后，修复方案大致有四种，分别对应不同的业务场景。
方案一：加长字段定义。如果业务上确实需要存储更长的内容，直接ALTER表扩展长度即可，这是最彻底的办法。DB2支持在线扩长VARCHAR字段，不会影响已有数据：
-- 将字段从50扩展到200
ALTER TABLE mytable ALTER COLUMN description SET DATA TYPE VARCHAR(200);
-- 扩完后建议reorg一下（部分版本需要）
CALL SYSPROC.ADMIN_CMD('REORG TABLE mytable');
方案二：写入前主动截断。如果业务允许丢弃尾部内容（比如日志摘要、展示用途的简介），可以在SQL里用SUBSTR控制长度：
INSERT INTO mytable(id, description) SELECT id, SUBSTR(description, 1, 200) FROM staging_table;
使用SUBSTR时要注意字节与字符的区别，在多字节码页下SUBSTR按字节截可能把一个汉字截成半个字节导致乱码，此时应改用SUBSTR的字符语义版本或CHARACTER_LENGTH配合处理。
方案三：修正程序端变量长度。Java中定义的VARCHAR绑定长度、C程序中EXEC SQL声明的宿主变量长度，都要与数据库字段长度匹配。例如COBOL里的PIC X(50)对应VARCHAR(50)，字段扩长后宿主变量也要同步改，否则数据库端扩了长程序端依然截断。
方案四：处理码页不一致问题。确认数据库服务端码页与客户端码页，尽量保持一致。可以查询当前配置：
db2 get db cfg for mydb | grep -i code -- 客户端码页 db2set DB2CODEPAGE
如果数据库是GBK而应用使用UTF-8，考虑将数据库迁移到UTF-8码页，或者在应用层统一转换为数据库码页后再计算长度，避免“字符数没超、字节数超了”的隐性截断。
四、预防措施与最佳实践
与其事后救火，不如在设计阶段就规避风险。建表时对文本字段的长度预留足够余量，特别是备注、描述、URL、JSON内容这类长度不可控的字段，可以考虑直接用VARCHAR加大长度，DB2最大支持32672字节，超出就用CLOB。从外部系统接收数据时，在接口层做长度校验，超长时要么拒绝要么明确截断策略，并把决策记入日志。
另外一个实用技巧是在应用里封装统一的入参校验方法，按目标字段的字节长度做预检查，而不是字符个数。Java中可以用str.getBytes(Charset.forName("GBK")).length来模拟数据库端的字节长度判断，与数据库行为保持一致。对于LOAD批量导入，建议总是配合异常表使用，把被拒行导出到独立表里事后分析，而不是让整个导入任务失败重来。
总结一下，22001本质上是长度校验失败，解决思路就是三步走：先用错误token和目录表定位字段，再对比定义长度与实际字节长度确认根因，最后根据业务需求选择扩长、截断、改程序或统一码页。掌握字节与字符的差异这个关键点，绝大多数22001问题都能在短时间内解决。
DB2SQLSTATE 22001字符串截断修改时间：2026-09-07 11:10:53