oracle解析sql时，绑定变量运行时类型与字段类型不一致必然触发隐式转换，导致索引失效；需确保声明类型、实际传入类型及v$sql_bind_capture中datatype_string三者严格一致，并通过执行计划predicate information验证。
变量声明类型与字段类型不一致直接触发隐式转换
oracle在解析sql时，会严格比对绑定变量的运行时类型与目标字段类型。一旦不匹配，优化器就自动在字段上套函数（如to_number、to_char），导致索引无法下推。这不是“可能”，而是必然行为。
典型场景：ACC_NBR是VARCHAR2字段，但存储过程里定义p_acc_nbr IN NUMBER，调用时传入数字字面量或NUMBER变量——Oracle就会生成TO_NUMBER("ACC_NBR") = :B1，索引立刻失效。
- 字段是
NUMBER→ 绑定变量必须声明为NUMBER，不能用VARCHAR2再TO_NUMBER()包装 - 字段是
DATE→ 参数必须是IN DATE，别收VARCHAR2再TO_DATE() - 字段是
VARCHAR2(32)→ 变量也得是VARCHAR2，且长度≥32，否则截断后二次转换风险上升
看执行计划里的Predicate Information才是铁证
光看代码声明没用，PL/SQL可能静默转类型。真正要确认是否发生隐式转换，必须查执行计划的Predicate Information部分：
- 出现
access("ID"=TO_NUMBER(:B1))→ 字段是NUMBER，但绑定变量实际传的是字符串 - 出现
filter(TO_CHAR("CREATED_DATE")='20240101')→ 字段是DATE，却对它用TO_CHAR包装 - 出现
COLLATE "USING_NLS_COMP"→VARCHAR2字段因NLS设置触发字符集隐式转换
更准的验证方式：把:p_id临时替换成字面量（比如123或'123'），跑EXPLAIN PLAN FOR。如果字面量走索引、变量不走，基本就是类型不一致。
V$SQL_BIND_CAPTURE能暴露真实运行时类型
代码里写p_id IN NUMBER不代表运行时真是NUMBER。PL/SQL赋值链中一次VARCHAR2→NUMBER转换，就可能让绑定变量在SQL层变成VARCHAR2。
执行完存储过程后，查：
SELECT name, datatype_string, value_string FROM V$SQL_BIND_CAPTURE WHERE sql_id = '你的SQL_ID' AND child_number = 0;
重点核对datatype_string：
- 目标字段是
NUMBER→ 这里必须显示NUMBER，若为VARCHAR2，说明上游传参或赋值已失真 - 目标字段是
DATE→ 这里不能是VARCHAR2，哪怕你写了v_dt := TO_DATE(p_str, 'YYYY-MM-DD')，也要确认v_dt确实被当DATE用了
动态拼接SQL和游标参数最容易踩坑
||拼接和游标传参是两个高频雷区：
- 写
'WHERE id = ' || p_id，而p_id是VARCHAR2→ 拼出WHERE id = '123'，触发隐式转换；应改用EXECUTE IMMEDIATE ... USING p_id - 游标定义为
FOR SELECT * FROM emp WHERE id = :p_id→ 调用OPEN cur_emp('123')就完蛋，必须OPEN cur_emp(123) -
v_id VARCHAR2(10) := '123';再传给NUMBER字段查询 → PL/SQL虽自动转成TO_NUMBER(v_id)，但这个转换发生在SQL解析前，仍会导致字段被包裹
最隐蔽的点在于：变量在PL/SQL块内类型“看起来正确”，但经过中间赋值、参数传递、游标打开等环节后，实际落到SQL引擎里的类型早已不是最初声明的那个。
