ORA-06502错误主因是变量或OUT参数声明长度小于实际值，需检查并扩大VARCHAR2长度（如姓名≥100、描述建议4000），或改用CLOB配合显式驱动设置；同时排查不可见字符及调用端registerOutParameter长度匹配。
存储过程中 ORA-06502 报错：变量长度不匹配直接触发截断
Oracle 存储过程里出现 ORA-06502: PL/SQL: numeric or value error: character string buffer too small，基本可锁定是 OUT 或 IN OUT 参数的声明长度小于实际返回值。比如存储过程定义了 v_name VARCHAR2(10)，但实际拼接或查询结果是 'Customer_2026_Q2_Report'（22 字符），调用时就会崩。
关键不是“值太长”，而是“接收容器太小”。Java/.NET 调用端传入的 registerOutParameter 长度也必须 ≥ 存储过程中该变量的声明长度，否则驱动层就提前截断，连进存储过程的机会都没有。
- 检查所有
OUT变量声明，把VARCHAR2(n)的n放宽到业务可能最大长度（如姓名字段至少 100，描述类字段建议 4000） - 若无法预估上限，改用
CLOB类型 +DBMS_LOB操作，但注意CLOB不支持直接赋值给普通字符串变量 - 调用方（如 Java 的
CallableStatement）必须显式设置setCharacterStream或registerOutParameter(index, Types.CLOB)，不能只靠类型推断
TRIM 和 RTRIM 不能解决根本问题，但能绕过部分隐形截断
有些截断不是因为内容长，而是因为源数据带不可见字符（如 Windows 换行 \r\n、全角空格、BOM 头）。即使字段声明为 VARCHAR2(200)，实际字节长度可能超限（尤其启用 UTF8MB4 后，一个 emoji 占 4 字节）。
TRIM 默认只去半角空格；RTRIM(column, CHR(10) || CHR(13)) 才能清理换行符；更稳妥的是用正则：REGEXP_REPLACE(column, '[[:cntrl:]]', '') 清掉所有控制字符。
- 别在 INSERT 前无脑
TRIM—— 它不处理 tab、null 字符、零宽空格（U+200B） - 如果字段用于模糊查询（
LIKE），清理后记得重建函数索引，否则WHERE TRIM(name) LIKE '%abc%'会全表扫 - 对日志类字段，建议入库前统一用
UTL_RAW.CAST_TO_VARCHAR2(UTL_ENCODE.BASE64_DECODE(UTL_RAW.CAST_TO_RAW(str)))预检非法字节（慎用，性能差）
SQL Server 存储过程里 @@ERROR 捕获不到截断，必须加 @@ROWCOUNT
SQL Server 对字符串截断采用“静默截断”策略：数据被砍掉、语句仍返回成功码，@@ERROR 保持为 0。这就导致主从表插入时，主表写入成功、从表字段被砍、事务看似提交，实则数据残缺。
正确做法是在每个 INSERT / UPDATE 后立刻判断：IF @@ERROR 0 OR @@ROWCOUNT 1。因为截断发生时，SQL Server 仍会返回 @@ROWCOUNT = 1，但后续校验逻辑（如触发器、计算列）可能失败并置 @@ERROR 非零。
- 不要依赖
TRY...CATCH—— 截断错误属于严重性级别 10~11，不进入 CATCH 块 - 批量操作时，
@@ROWCOUNT返回影响行数，需配合SET XACT_ABORT ON确保出错即回滚 - 若用
sp_executesql动态执行，必须在动态 SQL 内部做@@ERROR判断，外部无法感知
MySQL 存储过程报 Data truncated for column：严格模式才是关键开关
MySQL 默认是非严格模式，INSERT 遇到超长字符串只会警告（Warning 1265），语句继续执行。一旦开启 STRICT_TRANS_TABLES 或 STRICT_ALL_TABLES，它就变成错误并中断执行。
这个开关不在存储过程里设，而在会话或全局 SQL 模式中。所以同一个存储过程，在开发环境不报错、生产环境报错，大概率是两边 sql_mode 不一致。
- 查当前模式：
SELECT @@sql_mode;，确认是否含STRICT_* - 临时修复：
SET SESSION sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_DATE';（仅当前连接） - 永久修改需在
my.cnf中配置sql_mode，重启生效；但要注意老应用可能依赖非严格行为
真正难处理的不是“字段太短”，而是“谁在悄悄截断”——数据库驱动、ORM 框架、中间件、甚至前端 JS 的 .substring() 都可能成为黑盒截断点。排查时优先抓网络包看原始请求体长度，再比对服务端日志里的实际入参，最后才动数据库结构。
