IN用法失效主因是NULL和类型隐式转换：子查询含NULL致结果为UNKNOWN，字符串与数字混用时各数据库行为不一；NOT IN遇NULL恒不成立，应改用NOT EXISTS；超1000值需拆分或临时表；字符串列表须用预编译防注入。
IN 用法不对，查不到数据？先看 NULL 和类型隐式转换
多数人写 WHERE id IN (1, 2, 3) 没问题，但一旦换成子查询或字段拼接就失效。核心原因是：如果子查询返回 NULL，整个 IN 表达式结果为 UNKNOWN，被当作 FALSE 处理；另外，字符串和数字混用时，MySQL 可能做隐式转换（比如把 '1' 当成 1），而 PostgreSQL 或 SQL Server 则直接报错或不匹配。
- 子查询必须加
WHERE col IS NOT NULL过滤掉空值，否则id IN (SELECT x FROM t)在含NULL时恒为假 - 确保左右两边数据类型一致：
user_id IN (SELECT CAST(id AS CHAR) FROM users)不如统一用整型更安全 - PostgreSQL 中
text和varchar虽兼容，但带尾部空格时比较可能意外失败，建议显式TRIM()
NOT IN 为什么比 NOT EXISTS 慢还容易出错
NOT IN 看似简洁，实际是性能陷阱和逻辑坑的重灾区。它要求右侧集合**完全非空且无 NULL**，否则结果为空——这和直觉相反，而且优化器很难对大表子查询做有效索引下推。
- 只要子查询里有一个
NULL，NOT IN整个条件就永远不成立，连WHERE 1=1都救不回来 - 替代方案优先选
NOT EXISTS：它天然规避NULL问题，且能利用关联字段上的索引 - 示例对比：
SELECT * FROM orders o WHERE o.user_id NOT IN (SELECT u.id FROM users u WHERE u.status = 'active');
→ 改成：SELECT * FROM orders o WHERE NOT EXISTS (SELECT 1 FROM users u WHERE u.id = o.user_id AND u.status = 'active');
超过 1000 个值传给 IN，数据库开始卡顿甚至报错
Oracle 限制单次 IN 最多 1000 项；SQL Server 对参数数量没硬限但执行计划会退化；MySQL 虽无硬限，但超长列表会让解析、缓存、网络传输都变慢。
- 批量查询别硬拼
IN (v1,v2,...,v5000)，改用临时表或VALUES表构造（如 PostgreSQL 的SELECT * FROM t WHERE id IN (VALUES (1),(2),...)） - 应用层拆分：每批 500 个值，用
UNION ALL合并结果（注意去重逻辑是否受影响） - 如果只是校验存在性，考虑用
JOIN替代：把待查 ID 列表做成内存表或 CTE，再与主表LEFT JOIN ... WHERE right.id IS NULL
用 IN 匹配字符串列表时，引号和分隔符怎么处理才不出错
动态拼 SQL 是最常见翻车点。比如想查 status IN ('pending', 'processing')，但代码里拼成 "IN ('" + statusList.join("','") + "')"，一旦 statusList 为空或含单引号，就语法错误或 SQL 注入。
- 永远别手动拼字符串进
IN—— 用预编译参数（如 JDBC 的PreparedStatement）或 ORM 的批量参数绑定 - 如果必须拼，先转义单引号：
str.replace(/'/g, "''")（SQL Server）或str.replace(/'/g, "\'")（MySQL），但仍有注入风险 - JSON 字段场景别用
IN：想查tags @> '["a","b"]'，应该用 JSON 函数，不是把数组展开成字符串列表
IN 和 NOT IN 看似简单，真正卡住人的从来不是语法，而是 NULL 处理、类型一致性、参数规模和字符串边界这些细节。写完记得跑一遍含 NULL 值的测试数据，不然上线后查不到记录，第一反应永远是“数据丢了”，而不是“SQL 逻辑崩了”。
