绑定变量仅能替代值，不能替代表名、列名等SQL结构；结构部分须通过白名单、数据字典校验或DBMS_ASSERT.SIMPLE_SQL_NAME严格过滤后拼接，否则将触发ORA-00903/ORA-00904语法错误且破坏执行计划缓存与权限控制。
绑定变量只能替代值，不能替代SQL结构
Oracle 的 EXECUTE IMMEDIATE 和 USING 子句中的绑定变量（如 :1、:dept_id）在解析阶段就被数据库引擎识别为“运行时值占位符”，仅用于替换字面量数据（字符串、数字、日期等）。表名、列名、排序字段、JOIN 条件中的字段名属于 SQL 语句的**语法结构组成部分**，必须在硬解析（hard parse）前就完全确定。一旦用绑定变量试图替代它们，Oracle 会直接报 ORA-00903: invalid table name 或 ORA-00904: invalid identifier——这不是执行期错误，而是语法校验失败。
为什么设计上禁止结构绑定
允许绑定表名/列名会破坏 Oracle 的执行计划缓存机制：同一段 SQL 字符串（如 SELECT * FROM :table）若能动态指向不同表，其执行计划就无法复用，索引选择、统计信息应用、并行策略等都失去意义。更关键的是，它会让权限检查失效——用户可能有表 A 的 SELECT 权，但没表 B 的；如果表名可绑定，权限系统就无法在解析时锁定目标对象。
安全拼接表名和列名的实操底线
必须把动态部分从用户输入中彻底剥离，只允许从受控来源取值：
- 用白名单枚举：比如
sortField只能是"user_name"、"created_date"、"status"，其他一律拒掉 - 查数据字典校验存在性：
SELECT 1 FROM all_tables WHERE owner = 'SCHEMA_NAME' AND table_name = UPPER(:input_table)，再拼 - 用
DBMS_ASSERT.SIMPLE_SQL_NAME函数过滤：EXECUTE IMMEDIATE 'SELECT * FROM ' || DBMS_ASSERT.SIMPLE_SQL_NAME(v_table_name)，它会拒绝含点、空格、引号、分号的非法名 - 永远不用
QUOTENAME（那是 SQL Server 的），Oracle 对象名需大写+双引号包裹（如"My_Table"），但前提是已确认合法——双引号本身不防注入
常见踩坑点：看似参数化，实则仍拼接
以下写法看似“用了绑定”，实则危险或无效：
-
v_sql := 'SELECT * FROM ' || :table_name;——:table_name在这里根本不会被绑定，编译就报错 -
EXECUTE IMMEDIATE 'SELECT * FROM ' || v_table_var USING v_param;——USING只作用于 SQL 字符串内部的:占位符，对拼接部分无影响 - 把用户输入直接塞进
ORDER BY：'ORDER BY ' || user_input，哪怕后面跟USING也拦不住注入
真正难的不是“怎么拼”，而是“怎么证明拼出来的一定安全”——多数线上事故都出在白名单漏判、大小写转换不一致、或 schema 名未限定导致跨用户访问上。
