in基本写法为where column in (val1, val2, …)，字符串必须加单引号、数值可不加但需类型一致；常见错误包括括号缺失、字符串未引号致列名误判、null参与比较返回unknown、子查询返回多列或含null、空列表in()报错或返回空结果。
IN 查询的基本写法和常见错误
直接用 IN 是最简单的多值匹配方式，但很多人写错括号或引号导致语法报错。比如 WHERE status IN 'active', 'pending' 少了括号，正确写法必须是 WHERE status IN ('active', 'pending')。
注意：字符串值必须加单引号，数字可以不加，但混用时建议统一加引号避免隐式转换问题。MySQL 中 IN (1, '1') 可能触发类型转换，结果不可靠。
- 括号不能省略，
IN后必须是括号包裹的列表 - 空括号
IN ()在大多数数据库中会报错（如 PostgreSQL），MySQL 虽不报错但永远返回空结果 - NULL 不能用
=判断，但IN里包含NULL时整条表达式结果为UNKNOWN，相当于不匹配 —— 所以WHERE id IN (1, 2, NULL)实际等价于WHERE id IN (1, 2)
IN 和 OR 的性能差异与选择依据
看起来 status = 'active' OR status = 'pending' 和 status IN ('active', 'pending') 等价，但执行计划可能不同。现代优化器通常会把短 IN 列表重写成 OR 链，但长列表（比如几百个值）会让 OR 编译变慢、执行计划不稳定。
实际测试中，PostgreSQL 对超过 100 个值的 IN 列表可能放弃使用索引；SQL Server 在参数化查询中若用 IN @list（未展开）会完全无法走索引 —— 必须展开成字面量或改用临时表/表值参数。
- 少于 50 个值，用
IN更简洁可读 - 动态生成大量值时，避免拼接超长
IN字符串（易触发 SQL 注入或长度限制），改用JOIN或临时表 - Oracle 中
IN最多支持 1000 个元素，超限会报错ORA-01795: maximum number of expressions in a list is 1000
IN 配合子查询的典型陷阱
子查询用在 IN 右侧很常见，但容易忽略 NULL 和列数问题。比如 WHERE id IN (SELECT user_id FROM logs)，如果 logs.user_id 有 NULL，整个子查询结果集会包含 NULL，导致外层查询不返回任何行（因为 id = NULL 永远不成立）。
另一个坑是子查询返回多列：WHERE id IN (SELECT id, created_at FROM users) 会直接报错，IN 只接受单列子查询。
- 子查询务必加
WHERE col IS NOT NULL过滤掉空值，或改用EXISTS - 确保子查询只选一列，且类型与左值兼容（比如用
text匹配varchar通常没问题，但int和json就不行） - 子查询若可能为空（返回 0 行），
IN结果为FALSE，不会报错但逻辑上“无匹配”——这有时是预期行为，有时是 bug 来源
替代方案：什么时候不该用 IN
当要匹配的值来自应用层且数量极大（如导出的 10 万 ID 列表），硬塞进 IN 不仅慢，还可能突破数据库的 max_allowed_packet（MySQL）或语句长度限制（SQL Server）。这时该换思路。
真正高效的方案取决于场景：如果这些值能存进一张临时表，就用 JOIN；如果只是做存在性判断，EXISTS 通常比 IN 更早终止；如果是固定枚举集，考虑用 CASE WHEN 或查维表。
- 大批量 ID 匹配：建临时表 +
JOIN，比拼接 10 万项的IN快一个数量级 - 需要排除某些记录：优先用
NOT EXISTS，而不是NOT IN（后者遇子查询含NULL就全失效） - PostgreSQL 中对大列表可用
ANY(ARRAY[...])，性能接近IN且语法更灵活
IN 很方便，但它的边界条件（空值、长度、子查询结构）比表面看起来复杂得多，写之前先想清楚数据里有没有 NULL、会不会超长、要不要支持空结果集 —— 这些地方一漏，查出来的数据就静默错了。
