Oracle中IN列表超1000项报ORA-01795错误；MySQL虽无语法限制，但IN项过多（如5000+）易致优化器放弃索引而全表扫描，需用临时表、分批查询或类型统一等方案优化。
IN列表超过1000项直接报错或降级为全表扫描
Oracle里IN子句硬编码值超过1000个，会抛ORA-01795: maximum number of expressions in a list is 1000；MySQL虽不限制数量，但优化器在IN项过多（比如5000+）时大概率放弃使用索引，转而走全表扫描——不是因为语法错，是执行计划“算不过来”。
常见错误现象：EXPLAIN显示type=ALL、key=NULL，哪怕WHERE id IN (…)字段明明有索引。
- 用临时表替代大IN列表：先
INSERT INTO tmp_ids SELECT …，再JOIN tmp_ids，MySQL/PostgreSQL/Oracle都稳 - 分批查：把大IN拆成每500项一批，用
UNION ALL拼结果（注意去重逻辑是否允许） - 避免在应用层拼超长
IN字符串，尤其Java里用MyBatis<foreach>没设separator或open/close易漏括号，导致SQL语法错误
IN里的值类型不一致导致索引失效
IN括号内如果混用字符串和数字（比如WHERE status IN ('1', 2, '3')），MySQL会把整列隐式转成字符串比对，索引直接作废；PostgreSQL更严格，类型不匹配直接报错operator does not exist。
使用场景：从HTTP参数或JSON里取ID列表，没做类型归一化就塞进SQL。
- 统一转成目标字段类型：查
INT字段就全转INT，别留'123'这种字符串 - 用
CAST或::显式转换（如WHERE id IN (SELECT CAST(x AS INTEGER) FROM UNNEST(?))） - 检查执行计划里
Extra字段是否出现Using where; Using index——没这个组合，基本就是类型惹的祸
IN子查询返回NULL时整个条件恒假
WHERE id IN (SELECT user_id FROM logs WHERE type = 'error')，如果子查询结果为空或含NULL，整条IN判断结果是UNKNOWN，等价于FALSE，查不到任何数据。这和= ANY()行为一致，但很多人误以为“空结果集就当没条件”。
性能影响：子查询本身若没索引，每次执行都要全扫logs表，且无法利用外层id索引做半连接优化。
- 加
IS NOT NULL过滤：如WHERE id IN (SELECT user_id FROM logs WHERE type = 'error' AND user_id IS NOT NULL) - 改用
EXISTS：语义更清晰，且多数引擎能下推关联条件，避免空结果陷阱 - 确认子查询是否真需要实时执行——高频场景可预聚合到物化视图或缓存表
MySQL 8.0+ 的IN优化开关实际没开
MySQL 8.0引入range_optimizer_max_mem_size参数控制IN优化内存上限，默认16MB。但当IN列表解析后占用超限，优化器自动退回到传统嵌套循环，索引照样不走。
查当前值：SHOW VARIABLES LIKE 'range_optimizer_max_mem_size';，默认16777216字节，换算下来约支撑20万左右整型值（按每个值8字节估算），但实际受字符串长度、字符集影响极大。
- 调大该参数前先压测：内存涨了可能挤占buffer pool，反而拖慢整体QPS
- 线上库慎用
SET GLOBAL，优先在SQL hint里加/*+ SET_VAR(range_optimizer_max_mem_size = 67108864) */ - 比调参更稳的路：用
VALUES ROW()语法（MySQL 8.0.19+），如WHERE (id) IN (ROW(1),(2),(3))，优化器识别更准
真正麻烦的是那种“业务说必须一次查完10万ID”的需求——技术上能绕，但得提前跟产品对齐：是不是真不能分页？缓存过期策略能不能接住？这类问题藏在SQL背后，比执行计划难调。
