MySQL中IN条件的性能边界：是否需限制条目数或弃用？

是否需要为IN条件设定阈值？ #

没必要完全弃用IN条件，可以根据条目数量设定阈值来选择方案，而非一刀切。

针对你的场景分析 #

你的sso表有5万条记录，且已为s_id创建索引，要查询的目标ID仅20个，这种情况下直接使用IN查询是更优的选择，理由如下：

• 解析成本极低：包含20个ID的SQL语句简短，数据库解析、编译的开销几乎可以忽略。
• 索引利用率高：InnoDB会自动对IN列表中的ID排序，然后通过s_id索引快速定位匹配行，执行效率接近多次单ID查询的联合结果，还能减少网络交互和连接开销。
• 临时表额外开销更大：创建临时表需要额外的IO、内存资源，还要插入20条数据再做关联查询，整个流程的总开销远高于直接用IN查询。

什么时候该考虑临时表？ #

当IN条件中的条目数达到几百个（比如500+，具体阈值可根据自身数据库版本、硬件环境测试确定），或者ID列表动态生成且数量不稳定时，临时表方案会更合适：

1. 创建临时表并插入所有目标ID：

CREATE TEMPORARY TABLE temp_s_ids (s_id INT(11) NOT NULL PRIMARY KEY);
INSERT INTO temp_s_ids VALUES (1), (2), ..., (N);

2. 通过JOIN关联原表查询：

SELECT s.s_id, s.date, s.start, s.end, s.slots, s.capacity
FROM sso s
JOIN temp_s_ids t ON s.s_id = t.s_id;

这种方式能避免SQL语句过长导致的解析问题，同时优化器能更稳定地利用索引完成关联查询。

结论 #

仅20个ID时保留IN查询完全合理，无需使用临时表。

内容的提问来源于stack exchange，提问作者Abel