Oracle/MySQL/SQL Server 的 IN 子句均有硬性数量限制，需用临时表、分批 UNION ALL 或 PostgreSQL 的 UNNEST 等方案替代；临时表须建索引，空表时 IN(SELECT...) 返回 UNKNOWN，需加 IS NOT NULL 或改用 EXISTS。
Oracle 里 IN 子句超 1000 个值直接报 ORA-01795，MySQL 虽不报错但超过 5000 个值大概率触发全表扫描，SQL Server 则卡在约 2100 个参数——这不是配置能调出来的硬限制，必须换写法。
用临时表替代 IN 列表（Oracle/MySQL/PostgreSQL 通用）
把大批量值先写进数据库临时表或普通表，再通过 IN (SELECT ...) 或 JOIN 关联。优势是执行计划稳定、索引可用、避免 SQL 长度溢出。
- 临时表需提前建好索引，例如
CREATE INDEX idx_hours_temp ON hours_temp(hour)，否则关联时性能反而更差 - Oracle 全局临时表用
ON COMMIT DELETE ROWS，避免跨事务污染；MySQL 可用CREATE TEMPORARY TABLE，会话结束自动销毁 - 批量插入建议分批，每批 ≤ 1000 行，防止单条
INSERT触发同样限制 - 注意：若临时表为空，
IN (SELECT ...)整个条件结果为UNKNOWN，查不到任何数据，需加IS NOT NULL过滤或改用EXISTS
分批 + UNION ALL 拼接（无建表权限时的兜底方案）
将长列表切分为 ≤ 1000 项/批，生成多个 WHERE col IN (...) 子句，用 UNION ALL 合并。适用于无法创建辅助表、又必须单次请求返回全部结果的场景。
- 每批参数单独绑定，不能共用同一组占位符；Python 中
cursor.execute(sql, batch1 + batch2 + ...)需按顺序拼接参数列表 - 若两字段（如
HOUR和UnitScheduleId）长度不等，必须对齐批次逻辑，否则UNION ALL结果错位 - MySQL 中注意
max_allowed_packet上限，拼完的 SQL 总长度别超 4MB（默认值），否则连接直接中断 - 不推荐用
OR连接多段IN，语法易错且优化器难生成高效计划
PostgreSQL 用 UNNEST 替代 IN（仅限 PG）
PostgreSQL 下，WHERE id = ANY(ARRAY[...]) 或 WHERE id IN (SELECT UNNEST(?)) 比原生 IN (val1, val2, ...) 更可控——规划器能更好估算行数，减少执行计划漂移。
- 必须配合
CAST或显式类型声明，例如UNNEST($1::int[])，否则类型不匹配会报operator does not exist - 应用层传参要序列化为数组（如 Python 的
[1,2,3]），不是逗号字符串；JDBC 需用setArray()方法 - 如果查询还带其他条件（如时间范围），优先让索引字段（如
created_at）先过滤，再对小结果集做UNNEST匹配，避免大表上直接数组扫描
IN 查询慢但又不能改结构？加范围剪枝
当 data_id 是数值型且来源有序（比如从日志表按时间导出），可先取极值限定扫描范围：data_id >= :firstV AND data_id ，再叠 <code>AND data_id IN (...)。
- 这个技巧只在
firstV和lastV真实来自有序集合时有效；若随便取 min/max，可能仍扫几十万行 - 联合索引要包含该字段和其它高频过滤字段，例如
(example_id, data_id)，否则范围条件无法利用索引 - 如果
data_id是主键且连续，有时可直接去掉IN条件，只靠范围就命中全部目标行
真正容易被忽略的是类型一致性：哪怕只混一个字符串 '123' 进 INT 字段的 IN 列表，MySQL 就会整列转字符串比对，索引立即失效；PostgreSQL 直接报错。动手前先 SELECT typeof(x) 或检查 ORM 传参类型，比调优执行计划管用得多。
