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