ORA-06502错误本质是长度或类型不匹配，源于PL/SQL赋值、拼接、转换或返回时目标容器容量不足，常见于VARCHAR2声明过短、NUMBER精度不够、PLS_INTEGER超范围及隐式转换等场景。
ORA-06502 错误本质是长度或类型不匹配
这个错误不是“计算出错”，而是 PL/SQL 在赋值、拼接、转换或返回时，目标容器装不下实际数据。最常见的是 VARCHAR2 变量声明太短，但也会出现在 NUMBER 精度不足、PLS_INTEGER 超范围、甚至 LOGON 触发器里用户名截断等隐蔽场景。
检查变量声明和赋值是否越界
重点看报错堆栈里的行号（如 line 10），定位到具体赋值语句：
-
VARCHAR2(10)变量被赋了 12 个字符的字符串 → 改成VARCHAR2(100)或用DBMS_LOB处理超长内容 - 数值型变量如
NUMBER(3)存了1234→ 检查来源数据，或扩大精度声明 - 隐式转换陷阱：把
123456直接赋给VARCHAR2(5)，Oracle 会转成字符串'123456'（6 字符）→ 改用TO_CHAR(123456, 'FM99999')控制输出长度 - 使用
%TYPE时，源头字段本身已不够用 → 先查DESCRIBE table_name确认字段定义，再同步调整变量
排查 SELECT INTO 和动态 SQL 的缓冲区风险
SELECT ... INTO 是高危操作点，尤其当查询结果长度不确定时：
- 目标变量长度 MAX(LENGTH(column)) → 用
SELECT MAX(LENGTH(col)) FROM table预估上限 - 拼接字段（如
first_name || ' ' || last_name）可能超长 → 单独声明足够长的接收变量，或改用CLOB - 动态 SQL 中用
EXECUTE IMMEDIATE ... INTO→ 确保INTO变量长度 ≥ 所有可能返回值的最大长度；若不确定，优先用CLOB接收再截取
别忽略系统级触发器和函数返回类型
这类错误常在看似无关的操作中爆发，比如 sqlplus 登录失败、AWR 报告生成失败：
-
LOGON触发器里声明了VARCHAR2(10)存USER，但用户名是sqlreviewer（11 字符）→ 必须用VARCHAR2(30)或USER%TYPE - 函数返回
VARCHAR2(4000)，但逻辑中不断||拼接 → 一旦总长突破 4000 就崩，必须改返回类型为CLOB，并用DBMS_LOB.WRITEAPPEND - 调用方（如 Java）用
getString()读CLOB字段 → 会隐式转VARCHAR2导致ORA-22835→ 改用流式读取（getCharacterStream()）
真正麻烦的从来不是变量声明那行代码，而是上游数据长度不可控、触发器执行时机不可见、函数返回类型和调用方式不匹配——这些地方一漏，错误就藏得深、复现难、定位慢。
