oracle 不支持直接对 in 子句中的多个值使用单个绑定变量（如 :ids），必须为每个值单独声明绑定参数，或采用动态 sql 拼接、集合类型等替代方案。
oracle 不支持直接对 in 子句中的多个值使用单个绑定变量（如 :ids），必须为每个值单独声明绑定参数，或采用动态 sql 拼接、集合类型等替代方案。
在 Oracle JDBC（及基于其封装的 Groovy/Java 框架，如 Groovy Sql 或 Spring JDBC）中，IN 子句的绑定变量有严格限制：Oracle 服务端不接受将数组或列表作为单个绑定参数传入 IN (:param)。因此以下写法会失败：
String sql = "SELECT * FROM myTable WHERE id IN (:ids)" sqlConnection.query(sql, [ids: [111, 222, 333]]) // ❌ 抛出 java.sql.SQLException: Invalid column type
这是因为 Oracle 的绑定机制要求每个 : 占位符对应一个标量值（如 NUMBER、VARCHAR2），而 [111, 222, 333] 是一个集合，在 JDBC 层无法自动展开为多个绑定值。
✅ 正确解决方案
方案 1：动态生成占位符（推荐，适用于中小规模列表）
根据输入列表长度，动态构造等量的 ? 或 :id1, :id2, ... 占位符：
def ids = [111, 222, 333]
def placeholders = ids.collect { ":id${it}" }.join(', ')
String sql = "SELECT * FROM myTable WHERE id IN (${placeholders})"
sqlConnection.query(sql, ids.inject([:]) { map, id -> map["id${id}"] = id; map })
更简洁实用的 Groovy 写法（使用索引）：
def ids = [111, 222, 333]
def placeholders = (1..ids.size()).collect { ":id$_" }.join(', ')
String sql = "SELECT * FROM myTable WHERE id IN (${placeholders})"
def params = [:]
ids.eachWithIndex { val, idx -> params["id${idx+1}"] = val }
sqlConnection.query(sql, params)
⚠️ 注意：需确保 ids 非空（空列表需特殊处理，如 WHERE 1=0），且元素数量不宜过多（Oracle 单条 SQL 绑定变量上限通常为 32767，但实际建议 ≤ 1000 以保性能）。
方案 2：使用 Oracle 集合类型（高级，需数据库配合）
若允许建类型，可创建嵌套表类型并使用 TABLE() 函数：
-- 数据库执行一次（管理员权限） CREATE OR REPLACE TYPE number_list AS TABLE OF NUMBER;
Java/Groovy 中调用（需使用 OracleConnection 和 ARRAY）：
import oracle.sql.ARRAY
import oracle.sql.ArrayDescriptor
def descriptor = ArrayDescriptor.createDescriptor("NUMBER_LIST", conn)
def array = new ARRAY(descriptor, conn, ids as Object[])
def sql = "SELECT * FROM myTable WHERE id IN (SELECT COLUMN_VALUE FROM TABLE(?))"
sqlConnection.query(sql, [array])
该方式安全、高效，但依赖 Oracle 特有 API，可移植性差，适合企业级内部系统。
方案 3：字符串拼接（仅限可信数据，慎用！）
若 ids 来源绝对可信（如枚举常量、后台配置），可转义后拼入 SQL：
def idsStr = ids.collect { it.toString() }.join(',')
String sql = "SELECT * FROM myTable WHERE id IN (${idsStr})"
sqlConnection.query(sql, [:]) // 无绑定参数
⚠️ 严禁用于用户输入——存在严重 SQL 注入风险！
总结
- Oracle 原生不支持 IN (:list) 这类“集合绑定”，这是常见误区；
- 推荐优先使用动态占位符生成（方案 1），兼顾安全性、可读性与兼容性；
- 高并发/大数据量场景可评估 Oracle 集合类型（方案 2）；
- 永远避免未经校验的字符串拼接（方案 3）；
- 所有方案均需处理边界情况：空列表、null 值、超长列表的降级逻辑（如分批查询）。
