in操作符单次最多支持1000个值，超限需拆分或改用临时表、exists等方案；注意null无法参与in判断，子查询含null会导致条件失效。
直接用 IN 就行，但值超过 1000 个时必须拆分或换策略，否则报 ORA-01795: maximum number of expressions in a list is 1000。
IN 操作符的基本写法和边界限制
Oracle 对 IN 列表长度有硬性限制：单条语句中括号内最多允许 1000 个字面量值。这不是性能建议，是语法错误门槛。
- 合法：
WHERE status IN ('PENDING', 'APPROVED', 'REJECTED') - 非法（会直接报错）：
WHERE status IN ('A','B','C', ..., 'Z', ...)（共 1001 个） - 字符串值要用单引号，大小写敏感；数值不用引号，如
id IN (1, 2, 3) - NULL 不能用
IN判断，status IN (NULL, 'PENDING')永远不匹配 NULL —— 必须单独写status IS NULL
业务状态值超 1000 个时的三种实操方案
真实业务中，比如订单状态码、审批节点 ID、产品类目编码等，很容易突破 1000 个。不能硬拼 SQL，得换思路。
- 拆成多个
IN+OR：把 1500 个状态分成两组，WHERE status IN (...) OR status IN (...)。简单但 SQL 膨胀，可读性差，执行计划可能退化 - 用临时表 + 子查询：建
GLOBAL TEMPORARY TABLE插入所有状态值，再WHERE status IN (SELECT value FROM temp_status)。适合批量处理场景，且能复用 - 改用
EXISTS+ 关联表：如果这些状态值本就存在某张配置表（如ref_status），直接EXISTS (SELECT 1 FROM ref_status r WHERE r.code = t.status)。语义清晰、可走索引、无数量限制
IN 和子查询组合时的性能陷阱
写 WHERE status IN (SELECT code FROM ref_status WHERE active = 'Y') 看似优雅，但要注意三点：
- 子查询返回 NULL 会导致整条
IN判定为 UNKNOWN，结果集为空 —— 加AND code IS NOT NULL过滤掉 - 子查询若没走索引（比如
active列无索引），可能全表扫描ref_status，拖慢主查询 - Oracle 19c 默认对小结果集子查询做自动重写（
IN→JOIN），但若子查询含复杂逻辑（如UNION ALL、聚合），优化器可能放弃转换，导致嵌套循环效率低下
用 REGEXP_LIKE 替代 IN？不推荐
有人想用正则“偷懒”，比如 REGEXP_LIKE(status, '^PENDING$|^APPROVED$|^REJECTED$')。这在技术上可行，但：
- 无法利用
status列上的普通 B-Tree 索引，基本等于全表扫描 - 正则引擎开销远高于哈希查找，尤其当状态值固定、数量不多时，纯属降级
- 维护成本高：新增一个状态要改正则字符串，易出错；而
IN列表或配置表增删都是原子操作
真正容易被忽略的是 NULL 处理和子查询空值传导问题——哪怕你只传了 3 个状态值，只要子查询里混进一个 NULL，整个条件就失效。线上查不到数据时，先盯住 SELECT 子查询本身是否返回 NULL。
