使用 IN 查询静态值集合时，需注意：1. 空集合 IN () 语法错误，应判空后改用 1=0；2. IN 对 NULL 敏感，col IN (1, NULL) 不匹配 NULL，须显式用 IS NULL；3. 字符串值需加引号，数字可不加但建议统一转义防注入。
用 IN 查询静态值集合时要注意什么
直接写 IN 是最常见做法，但容易忽略括号里不能是空集合——比如 WHERE id IN () 会报语法错误。MySQL 和 PostgreSQL 都不支持空括号，SQL Server 也不行。如果集合来自程序拼接，得先判断是否为空，空时改用 1=0 或加兜底条件。
另外，IN 对 NULL 值敏感：WHERE col IN (1, 2, NULL) 实际等价于 col = 1 OR col = 2 OR col = NULL，而 col = NULL 永远为 false（除非用 IS NULL）。所以动态集合里混入 NULL 会导致意外交叉过滤。
- 拼接前检查集合长度，为空时改写成
WHERE 1=0 - 显式过滤掉
NULL值再进IN，或单独用IS NULL处理 - 字符串值必须加引号，数字不用，但程序生成时建议统一转义防注入
PostgreSQL 中用 ANY 替代 IN 更灵活
ANY 能直接对接数组或子查询结果，避免字符串拼接风险。比如从应用传入一个整数数组 {1,5,9}，可以直接：WHERE id = ANY(ARRAY[1,5,9]) 或 WHERE id = ANY($1)（绑定参数）。
它比 IN 多一个优势：支持 NOT ANY，且对空数组安全——id = ANY(ARRAY[]::int[]) 返回空结果，不报错。
- 用
ARRAY[...]字面量时注意类型一致，必要时加类型转换如::text[] - 配合
unnest()可展开逗号分隔字符串：WHERE id = ANY(ARRAY(SELECT unnest(string_to_array('1,2,3', ','))::int)) - 子查询返回单列时，
id = ANY(SELECT x FROM t)合法，但性能可能不如IN，需看执行计划
MySQL 8.0+ 支持 JSON_CONTAINS 处理动态 JSON 数组
如果动态集合以 JSON 字符串形式传入（比如 '[1,5,9]'），MySQL 8.0 起可用 JSON_CONTAINS：WHERE JSON_CONTAINS('[1,5,9]', CAST(id AS JSON))。这绕开了 SQL 拼接，也规避了 IN 空集合问题。
但注意：左侧必须是 JSON 值，右侧要转成 JSON 类型；数值比较时类型要匹配，CAST('1' AS JSON) 和 CAST(1 AS JSON) 在 JSON 中不等价。
- 确保传入的 JSON 字符串合法，否则
JSON_CONTAINS返回NULL - 索引无法生效，大数据量慎用
- 字符串字段匹配需用
JSON_CONTAINS(json_col, '"value"')，引号不能漏
用临时表或 CTE 避免拼接，适合大集合或复用场景
当动态集合元素超过几百个，或者同一集合要在多个地方用，硬拼 IN 或传 JSON 效率低、可读差。更稳的方式是把集合写入临时表或 CTE：
WITH target_ids AS ( SELECT 1 AS id UNION ALL SELECT 5 UNION ALL SELECT 9 ) SELECT * FROM users u JOIN target_ids t ON u.id = t.id;
CTE 在 PostgreSQL/SQL Server/MySQL 8.0+ 都支持；临时表在各库都稳定，且能建索引。关键是——集合数据不再嵌在 WHERE 里，逻辑分离，调试和复用都方便。
- CTE 不支持参数化，实际要用时得靠应用层生成完整 SQL
- 临时表记得显式
DROP（除非会话级自动清理） - Oracle 用户注意：CTE 写法一样，但
WITH必须是语句开头
真正麻烦的不是语法怎么写，而是集合来源不可控——用户输入、API 参数、配置文件……这些地方漏校验，后面所有方案都会崩。别只盯着 SQL 怎么写，先守住输入入口。
