在java.sql实例中使用SQL IN子句的最佳变通方法是什么?由于SQL注入攻击安全问题，不支持多值的PreparedStatement:一个?占位符表示一个值，而不是一个值列表。
考虑下面的SQL语句:
SELECT my_column FROM my_table where search_column IN (?)
使用preparedStatement。setString(1， "'A'， 'B'， 'C'");本质上是一种无用的尝试，试图解决使用原因?首先。
有什么可行的解决办法?
当前回答
只是为了完整性:只要值集不是太大，您也可以简单地用字符串构造语句，如
... WHERE tab.col = ? OR tab.col = ? OR tab.col = ?
然后你可以把它传递给prepare()，然后在循环中使用setXXX()来设置所有的值。这看起来很讨厌，但许多“大型”商业系统通常都会这样做，直到达到特定于db的限制，例如Oracle中的语句为32 KB(我认为是)。
当然，您需要确保集合永远不会不合理地大，或者在这种情况下进行错误捕获。
其他回答
遵循亚当的想法。让你的准备语句select my_column from my_table where search_column in (#) 创建一个字符串x，并根据你的值列表用一些“?，?，?”填充它 然后只需更改查询中的#为您的新字符串x填充
我的解决方案(JavaScript)
var s1 = " SELECT "
+ "FROM table t "
+ " where t.field in ";
var s3 = '(';
for(var i =0;i<searchTerms.length;i++)
{
if(i+1 == searchTerms.length)
{
s3 = s3+'?)';
}
else
{
s3 = s3+'?, ' ;
}
}
var query = s1+s3;
var pstmt = connection.prepareStatement(query);
for(var i =0;i<searchTerms.length;i++)
{
pstmt.setString(i+1, searchTerms[i]);
}
SearchTerms是包含你的输入/键/字段等的数组
PreparedStatement没有提供任何处理SQL IN子句的好方法。根据http://www.javaranch.com/journal/200510/Journal200510.jsp#a2“你不能替代那些意味着成为SQL语句一部分的东西。这是必要的，因为如果SQL本身可以更改，驱动程序就不能预编译语句。它还具有防止SQL注入攻击的良好副作用。”我最终使用了以下方法:
String query = "SELECT my_column FROM my_table where search_column IN ($searchColumns)";
query = query.replace("$searchColumns", "'A', 'B', 'C'");
Statement stmt = connection.createStatement();
boolean hasResults = stmt.execute(query);
do {
if (hasResults)
return stmt.getResultSet();
hasResults = stmt.getMoreResults();
} while (hasResults || stmt.getUpdateCount() != -1);
我只是为此制定了一个特定于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.
但它确实有效。
这不是理想的做法，但它很简单，大多数时候对我来说都很有效。
where ? like concat( "%|", TABLE_ID , "|%" )
然后你穿过?|1|，|2|，|3|，…|
