在java.sql实例中使用SQL IN子句的最佳变通方法是什么?由于SQL注入攻击安全问题，不支持多值的PreparedStatement:一个?占位符表示一个值，而不是一个值列表。
考虑下面的SQL语句:
SELECT my_column FROM my_table where search_column IN (?)
使用preparedStatement。setString(1， "'A'， 'B'， 'C'");本质上是一种无用的尝试，试图解决使用原因?首先。
有什么可行的解决办法?
当前回答
遵循亚当的想法。让你的准备语句select my_column from my_table where search_column in (#) 创建一个字符串x，并根据你的值列表用一些“?，?，?”填充它 然后只需更改查询中的#为您的新字符串x填充
其他回答
似乎还没有人建议使用现成的查询构建器，比如jOOQ或QueryDSL，甚至Criteria query，它们可以开箱即用地管理动态IN列表，可能包括对可能出现的所有边缘情况的管理，例如:
运行到Oracle的每个IN列表最多1000个元素(与绑定值的数量无关) 遇到任何驱动程序的绑定值的最大数目，这是我在这个答案中记录的 遇到游标缓存争用问题，因为太多不同的SQL字符串被“硬解析”，执行计划不能再缓存了(jOOQ和最近Hibernate也通过提供IN列表填充来解决这个问题)
(免责声明:我为jOOQ背后的公司工作)
这适用于我(伪docode):
public class SqlHelper
{
public static final ArrayList<String>platformList = new ArrayList<>(Arrays.asList("iOS","Android","Windows","Mac"));
public static final String testQuery = "select * from devices where platform_nm in (:PLATFORM_NAME)";
}
指定绑定:
public class Test extends NamedParameterJdbcDaoSupport
public List<SampleModelClass> runQuery()
{
//define rowMapper to insert in object of SampleClass
final Map<String,Object> map = new HashMap<>();
map.put("PLATFORM_LIST",DeviceDataSyncQueryConstants.platformList);
return getNamedParameterJdbcTemplate().query(SqlHelper.testQuery, map, rowMapper)
}
好吧，所以我不记得我之前是如何(或在哪里)这样做的，所以我来堆栈溢出来快速找到答案。我很惊讶我不能。
所以，很久以前我是用这样的语句来解决IN问题的:
where myColumn in (select regexp_substr(:myList，'[^，]+'， 1, level) from dual connect by regexp_substr(:myList，'[^，]+'， 1, level) not null)
将myList参数设置为逗号分隔的字符串:a,B,C,D…
注意:该参数必须设置两次!
而不是使用
SELECT my_column FROM my_table where search_column IN (?)
使用Sql语句作为
select id, name from users where id in (?, ?, ?)
and
preparedStatement.setString( 1, 'A');
preparedStatement.setString( 2,'B');
preparedStatement.setString( 3, 'C');
或者使用存储过程，这将是最好的解决方案，因为sql语句将被编译并存储在数据库服务器中
我遇到了一些与准备好的语句相关的限制:
The prepared statements are cached only inside the same session (Postgres), so it will really work only with connection pooling A lot of different prepared statements as proposed by @BalusC may cause the cache to overfill and previously cached statements will be dropped The query has to be optimized and use indices. Sounds obvious, however e.g. the ANY(ARRAY...) statement proposed by @Boris in one of the top answers cannot use indices and query will be slow despite caching The prepared statement caches the query plan as well and the actual values of any parameters specified in the statement are unavailable.
在建议的解决方案中，我会选择一个不会降低查询性能并且查询次数较少的解决方案。这将是#4(批处理少数查询)从@Don链接或指定NULL值为不需要的'?@Vladimir Dyuzhev提出的标记
