Scala中如何用PreparedStatement处理带IN条件的动态多值查询

一、先解决报错问题 #

你遇到的ERROR: operator does not exist: character varying = character varying[]，核心原因是PostgreSQL中IN (?)语法不支持直接接收数组参数——IN需要的是离散值列表，而你传入的是VARCHAR[]类型的数组，两者类型不匹配。

修正方法很简单，把SQL中的IN (?)替换为= ANY(?)：

select my_cols
from my_table a
join my_other_table b
on a.join_key = b.join_key
where my_id_column = ANY(?);

ANY操作符专门用于匹配数组元素，和你通过conn.createArrayOf传入的数组参数完全兼容，能直接解决类型不匹配问题。

二、关于PreparedStatement的复用与线程安全问题 #

你复用同一个PreparedStatement处理分块的思路是对的，并没有浪费——数据库会缓存这个预编译语句的执行计划，后续每次仅替换参数执行，比每次创建新语句效率更高。但要注意一个严重问题：PreparedStatement不是线程安全的，你用chunks.par.map并行操作同一个pstmt实例，会导致多个线程同时修改参数、执行查询，出现参数混乱或查询结果错误的情况。

解决这个问题的两种方案：

• 改用串行处理：把par.map换成普通的map，单线程依次处理每个分块，避免并发冲突。
• 并行但独立创建资源：如果追求并行效率，每个分块单独从连接池获取连接并创建PreparedStatement，但要注意控制并行度，避免耗尽连接池资源。

三、大IN条件用PreparedStatement还是Statement？ #

不建议改用Statement，原因如下：

1. 执行计划缓存优势：PreparedStatement的预编译语句可被数据库缓存，分块执行的20次查询（2万条分1000条/块）会复用同一个执行计划；而Statement每次执行都要重新解析拼接后的SQL，数据库需要生成20个不同的执行计划，效率更低。
2. 代码简洁性与可靠性：用PreparedStatement不需要手动拼接IN列表的逗号、引号，避免了字符串拼接可能出现的语法错误（比如ID包含特殊字符时），代码更易维护。
3. 性能差异：即使不关心SQL注入，PreparedStatement在大分块场景下的执行效率也优于Statement。

修正后的代码示例（串行版） #

val srcIdLookupFuture = Future[List[List[Any]]] {
  if (srcIdList.nonEmpty) { //srcIdList is like 15k items
    val sql = """select my_cols
               | from my_table a
               | join my_other_table b
               | on a.join_key = b.join_key
               | where my_id_column = ANY(?);""".stripMargin
    val conn: Connection = connectionPool.getConnection
    val pstmt: PreparedStatement = conn.prepareStatement(sql)
    val chunks: List[List[String]] = srcIdList.sliding(1000, 1000).toList
    try {
      chunks.map(chunk => {
        pstmt.setArray(1, conn.createArrayOf("VARCHAR", chunk.toArray))
        val rs: ResultSet = pstmt.executeQuery()
        getResults(rs)
      }).flatten.toList
    } finally {
      pstmt.close()
      conn.close()
    }

  } else List(List())

}

内容的提问来源于stack exchange，提问作者J.Hammond