Oracle动态SQL性能差主因是未正确使用绑定变量：仅参数部分应绑定，表名/列名等结构拼接仍致硬解析；需确保SQL文本完全一致、USING显式传参、应用层用#{}或PreparedStatement配合，否则无法复用执行计划。
oracle里动态sql性能差，八成是因为没用对绑定变量——不是加了冒号就万事大吉，关键在于让sql文本真正“稳定下来”，否则照样触发硬解析。
动态SQL中EXECUTE IMMEDIATE怎么写才不硬解析
很多人以为只要在EXECUTE IMMEDIATE里写:bind_var就算用了绑定变量，但实际常踩的坑是拼接了字段名、表名或WHERE条件片段。Oracle只认SQL字符串完全一致，一旦有拼接，每次生成的sql_text都不同，硬解析照旧。
- ❌ 错误：表名/列名拼接 →
EXECUTE IMMEDIATE 'SELECT ' || col_name || ' FROM ' || tbl_name || ' WHERE id = :id' USING v_id; - ✅ 正确：仅参数部分绑定 →
EXECUTE IMMEDIATE 'SELECT name, status FROM orders WHERE order_id = :oid' USING in_order_id; - ⚠️ 注意：
USING子句必须显式列出所有变量，不能漏传；类型要匹配（如DATE字段别传VARCHAR2字符串）
DBMS_SQL批量执行时如何避免重复解析
DBMS_SQL比EXECUTE IMMEDIATE更底层，也更容易误操作。它默认每次PARSE都会走硬解析，除非你手动复用游标句柄并只BIND_VARIABLE和EXECUTE。
- ✅ 正确流程：一次
OPEN_CURSOR→ 一次PARSE→ 多次BIND_VARIABLE+EXECUTE→ 最后CLOSE_CURSOR - ❌ 常见错误：循环内反复
OPEN_CURSOR+PARSE，等于每条都硬解析 - ? 提示：用
DBMS_SQL.LAST_ROW_COUNT确认是否真复用了执行计划，若每次EXECUTE后PARSE_CALLS没增加，说明成功软解析
应用层调用动态SQL时，ORM或JDBC怎么配合
即使PL/SQL写了绑定变量，如果Java或Python端用Statement拼字符串，或者MyBatis里写了${}而不是#{}，照样白搭。
- ❌ JDBC错例：
String sql = "SELECT * FROM user WHERE id = " + userId;→ 直接字符串拼接，无绑定 - ✅ JDBC正例：
PreparedStatement ps = conn.prepareStatement("SELECT * FROM user WHERE id = ?"); ps.setInt(1, userId); - ⚠️ MyBatis注意：
#{id}走预编译（安全且绑定），${id}是字符串替换（危险且必硬解析） - ? 验证方式：查
V$SQL中sql_text是否含:或?，且executions远大于parse_calls
哪些动态SQL场景根本没法用绑定变量
不是所有动态SQL都能绑定。当结构本身不确定时（比如列数、表连接关系、ORDER BY字段随业务变化），硬解析无法避免，这时得换思路。
- ⛔ 真没法绑定的情况：动态拼接
GROUP BY字段、UNION ALL分支数量不固定、分表路由导致表名必须计算 - ? 替代方案：用
DBMS_SQL缓存多个常用模板游标，按业务类型分组复用；或结合SQL Plan Management (SPM)固化高频执行计划 - ⚠️ 特别小心：
CURSOR_SHARING = FORCE虽能自动转字面量为绑定变量，但在复杂SQL或存在隐式转换时可能生成次优执行计划，生产环境慎开
最易被忽略的一点：绑定变量生效的前提是SQL文本从进入Oracle共享池那一刻起就完全一致——这要求从应用拼接、驱动层封装、到PL/SQL执行，每一环都不能破坏这个一致性。少一个?、多一个空格、错一个大小写，都可能导致前功尽弃。
