IN列表过大会导致SQL Server硬解析耗时飙升，因需逐个解析参数化并生成执行计划，编译开销近似线性增长；MySQL则因eq_range_index_dive_limit限制触发统计误判而选错执行计划；且IN破坏索引范围扫描能力，易退化为多次点查；临时表替代方案若未建索引、统计不准或批量插入不当，同样失效。
IN列表过大导致SQL Server硬解析耗时飙升
SQL Server遇到几万个字面量的IN语句（比如id IN ('a','b','c',...)），首次执行慢到秒级，不是因为查询本身卡在执行阶段，而是卡在**SQL编译解析**上。SQL Server要把整个超长IN列表逐个解析、参数化、生成执行计划——文本越大，硬解析越重。第二次执行快，是因为计划缓存命中，和索引无关。
- 硬解析开销与
IN中元素个数呈近似线性增长，10万常量可能让编译耗时达数秒 - 即使
id字段有索引，也救不了编译慢；索引只影响执行阶段，不加速解析 - 并发高时，大量线程排队等编译完成，容易触发
CMEMTHREAD或SOS_SCHEDULER_YIELD等待
MySQL中eq_range_index_dive_limit触发索引统计误判
MySQL对IN查询的代价估算机制会主动“偷懒”：当IN值数量 ≥ eq_range_index_dive_limit（默认200），它放弃扫描索引树（index dive），改用粗略的索引统计（index statistics）估算行数。结果往往是低估/高估严重，最终选错执行计划——比如该走索引却选了全表扫描。
- 检查当前值：
SHOW VARIABLES LIKE 'eq_range_index_dive_limit'; - 临时调高（仅限该查询）：
SELECT /*+ SET_VAR(eq_range_index_dive_limit = 2000) */ * FROM t WHERE id IN (...); - 注意：盲目调高会导致单次解析变慢，需权衡；生产环境建议≤500
IN列表破坏索引范围扫描能力
数据库优化器通常把IN (v1, v2, ..., vn)转成多个等值条件的并集。但当v1..vn离散且无序时，无法合并为连续范围，也就没法利用B+树的范围扫描特性。哪怕字段有索引，实际执行仍可能是n次独立的点查（Index Seek），叠加I/O和CPU开销后，整体比一次范围扫描慢得多。
- 典型现象：
data_id IN (1, 100, 5000, 99999)→ 四次Seek；而data_id BETWEEN 1 AND 99999→ 一次Range Scan - 如果
data_id是主键或唯一索引，且传入的ID列表本身有序、密集，可先取MIN()和MAX()加范围过滤，再用IN兜底去噪 - 但若列表来自用户随意勾选（如前端多选框），顺序和密度不可控，这条路就失效
替代IN的方案里最容易被忽略的坑
用临时表 + JOIN替代IN是主流解法，但实操中几个细节常被跳过，直接导致性能没改善甚至更差：
- 临时表必须建索引——SQL Server的
#tmp默认无索引，JOIN时变成Nested Loop + Table Scan - MySQL的
CREATE TEMPORARY TABLE不支持全文索引，也不支持ANALYZE TABLE，统计信息不准会影响JOIN选择 - PostgreSQL的
UNLOGGED临时表虽快，但在事务回滚时不会自动清理，残留数据可能污染后续查询 - 所有数据库中，临时表插入都应使用
BULK INSERT或批量绑定（如JDBC的addBatch），单条INSERT几千次等于把网络和解析压力从SQL层转移到应用层
真正卡住性能的往往不是“有没有索引”，而是“数据库有没有机会用上索引”。IN列表一旦失控，它最先杀死的是SQL的可预测性——解析时间飘忽、执行计划抖动、资源争用隐匿。控制输入规模、拆分逻辑边界、把动态值移出SQL文本本身，比调优单条语句重要得多。
