大多数sql数据库不支持直接将应用层list传入in子句，因语法要求in后为字面量列表如(1,2,3)，而非字符串或对象；需由orm展开占位符、数据库函数（如postgresql的unnest、mysql的json_contains）或分批查询实现安全高效匹配。
子查询不能直接用 IN 匹配传入的 List 参数？
大多数 SQL 数据库（如 MySQL、PostgreSQL、SQL Server）本身不支持“把一个应用层的 List 直接塞进 IN 子句”——你传入的不是语法合法的值列表，而是个字符串或对象。比如 Java 的 MyBatis 里写 WHERE id IN #{idList}，若 idList = [1,2,3]，实际拼出的可能是 WHERE id IN '[1,2,3]'，结果全错。
- 真正生效的
IN必须是WHERE id IN (1, 2, 3)，括号内是逗号分隔的字面量或表达式 - 动态 List 需由客户端/ORM 拆成独立参数，或靠数据库函数展开
- 硬拼字符串（如
"'"+ids.join("','")+"'"）有 SQL 注入风险，不推荐
PostgreSQL 怎么用 UNNEST 把数组参数转成行？
PostgreSQL 支持数组类型，且 UNNEST 可将数组展开为结果集，配合 IN 或 = ANY 使用最稳妥。
- 传参时用 PostgreSQL 原生数组格式：例如 JDBC 中设参数为
Array类型，值为{1,2,3} - 写法一（推荐）：
WHERE id = ANY(?)，? 绑定Integer[] {1,2,3} - 写法二：
WHERE id IN (SELECT UNNEST(?))，同样绑定数组参数 - 注意：
UNNEST返回多行，不能直接用于标量上下文（如SELECT UNNEST(ARRAY[1,2]) + 1会报错）
MySQL 和 SQL Server 没有数组类型，怎么安全传 List？
这两者没原生数组支持，得靠 ORM 或驱动层生成占位符，或用 JSON + 函数解析（MySQL 5.7+ / SQL Server 2016+）。
- MyBatis（MySQL）常用：
WHERE id IN <foreach item="id" collection="idList" open="(" separator="," close=")">#{id}</foreach>—— 自动生成(?, ?, ?) - MySQL 8.0+ 可用
JSON_CONTAINS：WHERE JSON_CONTAINS('["1","2","3"]', CAST(id AS JSON))，但id需转 JSON，索引失效 - SQL Server 可用
STRING_SPLIT：WHERE id IN (SELECT value FROM STRING_SPLIT(@idList, ','))，但@idList必须是字符串'1,2,3'，且value是NVARCHAR，需显式转换类型
为什么别在子查询里用 IN 套大结果集？
当子查询返回几千行，再套 IN 匹配，性能会断崖下跌——尤其 MySQL 5.6/5.7 对 IN (subquery) 优化差，可能全表扫描。
- 替代方案：改用
EXISTS或JOIN，让优化器走关联计划 - 例如：
WHERE EXISTS (SELECT 1 FROM allowed_ids a WHERE a.id = t.id)比WHERE t.id IN (SELECT id FROM allowed_ids)更稳 - 如果 List 是应用层小集合（IN (?, ?, ?)；若是大集合，应先入库临时表再 JOIN
真正麻烦的不是语法怎么写，而是搞清参数到底以什么形式落到 SQL 里——是字符串、数组、JSON 还是多个独立绑定变量。不同数据库、不同驱动、不同 ORM 处理方式差异极大，光看 SQL 本身容易漏掉这一层。
