只是为了完整性:只要值集不是太大，您也可以简单地用字符串构造语句，如

... WHERE tab.col = ? OR tab.col = ? OR tab.col = ?

然后你可以把它传递给prepare()，然后在循环中使用setXXX()来设置所有的值。这看起来很讨厌，但许多“大型”商业系统通常都会这样做，直到达到特定于db的限制，例如Oracle中的语句为32 KB(我认为是)。

当然，您需要确保集合永远不会不合理地大，或者在这种情况下进行错误捕获。

只是为了完整性:只要值集不是太大，您也可以简单地用字符串构造语句，如

... WHERE tab.col = ? OR tab.col = ? OR tab.col = ?

然后你可以把它传递给prepare()，然后在循环中使用setXXX()来设置所有的值。这看起来很讨厌，但许多“大型”商业系统通常都会这样做，直到达到特定于db的限制，例如Oracle中的语句为32 KB(我认为是)。

当然，您需要确保集合永远不会不合理地大，或者在这种情况下进行错误捕获。

我的解决方案是:

create or replace type split_tbl as table of varchar(32767);
/

create or replace function split
(
  p_list varchar2,
  p_del varchar2 := ','
) return split_tbl pipelined
is
  l_idx    pls_integer;
  l_list    varchar2(32767) := p_list;
  l_value    varchar2(32767);
begin
  loop
    l_idx := instr(l_list,p_del);
    if l_idx > 0 then
      pipe row(substr(l_list,1,l_idx-1));
      l_list := substr(l_list,l_idx+length(p_del));
    else
      pipe row(l_list);
      exit;
    end if;
  end loop;
  return;
end split;
/

现在你可以使用一个变量来获取表中的一些值:

select * from table(split('one,two,three'))
  one
  two
  three

select * from TABLE1 where COL1 in (select * from table(split('value1,value2')))
  value1 AAA
  value2 BBB

因此，预处理语句可以是:

  "select * from TABLE where COL in (select * from table(split(?)))"

问候,

哈维尔·伊瓦内斯

我只是为此制定了一个特定于postgresql的选项。它有点像黑客，有自己的优缺点和局限性，但它似乎是有效的，而且不局限于特定的开发语言、平台或PG驱动程序。

当然，诀窍是找到一种方法，将任意长度的值集合作为单个参数传递，并让db将其识别为多个值。我的解决方案是从集合中的值构造一个带分隔符的字符串，将该字符串作为单个参数传递，并使用string_to_array()与PostgreSQL正确使用它所需的强制转换。

因此，如果你想搜索“foo”，“blah”和“abc”，你可以将它们连接成一个字符串，如:'foo,blah,abc'。下面是直接的SQL语句:

select column from table
where search_column = any (string_to_array('foo,blah,abc', ',')::text[]);

显然，您可以将显式强制转换更改为您想要的结果值数组——int、text、uuid等。因为函数接受一个字符串值(或者两个，如果你也想自定义分隔符)，你可以在准备好的语句中作为参数传递它:

select column from table
where search_column = any (string_to_array($1, ',')::text[]);

这甚至足够灵活，可以支持like比较:

select column from table
where search_column like any (string_to_array('foo%,blah%,abc%', ',')::text[]);

Again, no question it's a hack, but it works and allows you to still use pre-compiled prepared statements that take *ahem* discrete parameters, with the accompanying security and (maybe) performance benefits. Is it advisable and actually performant? Naturally, it depends, as you've got string parsing and possibly casting going on before your query even runs. If you're expecting to send three, five, a few dozen values, sure, it's probably fine. A few thousand? Yeah, maybe not so much. YMMV, limitations and exclusions apply, no warranty express or implied.

但它确实有效。

对于某些情况，regexp可能会有所帮助。 下面是我在Oracle上查看的一个例子，它是有效的。

select * from my_table where REGEXP_LIKE (search_column, 'value1|value2')

但它也有一些缺点:

它应用的任何列都应该转换为varchar/char，至少是隐式转换。 使用特殊字符时要小心。 它会降低性能——在我的例子中，in版本使用索引和范围扫描，而REGEXP版本执行全扫描。

只是为了完整起见，因为我没有看到其他人提出这个建议:

在实现上述任何复杂的建议之前，请考虑SQL注入是否确实是您的场景中的一个问题。

在许多情况下，提供给In(…)的值是一个id列表，这些id以某种方式生成，您可以确保不可能进行注入…(例如，之前select some_id from some_table where some_condition.)

如果是这种情况，您可能只是连接这个值，而不为它使用服务或准备好的语句，或将它们用于此查询的其他参数。

query="select f1,f2 from t1 where f3=? and f2 in (" + sListOfIds + ");";