IN 列表超 1000 项易致查询变慢或超时，应避免应用层拼接长 IN；优先用 JOIN 或临时表替代，建索引、批量插入、注意类型与字符集一致。
IN 列表超过 1000 项时查询变慢甚至超时
MySQL 对 IN 子句本身没有硬性数量限制，但实际执行中，过长的 IN 列表会引发解析开销、执行计划退化、内存占用飙升等问题。尤其当值来自应用层拼接（如 WHERE id IN (1,2,3,……,5000)），优化器可能放弃使用索引，转为全表扫描。
- 避免在应用层拼超长
IN字符串；500 以上就该警惕，1000+ 基本属于危险区 - 确认字段有有效索引：
EXPLAIN中type应为range或ref，不是ALL - 若值来自另一张表，优先改用
JOIN或临时表，而非把结果取出来再拼IN - MySQL 8.0+ 可考虑用
VALUES ROW()构造行集合，比纯IN更可控（但仍有上限）
用临时表替代大 IN 查询的实操要点
把大批量 ID 先写入临时表，再通过 JOIN 关联，是更稳定、可预测的方案。关键不在“建表”，而在“怎么建”和“怎么用”。
- 用
CREATE TEMPORARY TABLE，不是普通表——避免锁表、权限问题，且会话结束自动清理 - 临时表必须建索引：
CREATE INDEX idx_tmp_id ON tmp_ids(id)，否则JOIN退化为嵌套循环 - 插入数据别用单条
INSERT：批量插入（INSERT INTO tmp_ids VALUES (1),(2),(3)）比逐条快 10 倍以上 - 注意字符集 / 排序规则匹配：如果主表
id是VARCHAR且带utf8mb4_0900_as_cs，临时表字段也得一致，否则隐式转换导致索引失效
LEFT JOIN 临时表后结果为空的常见原因
很多人建好临时表、JOIN 后发现没返回任何数据，不是逻辑错，而是几个隐蔽但高频的坑。
-
NULL值干扰：临时表里混入了NULL，而JOIN条件字段非空，NULL = anything永远为FALSE - 数据类型不一致：比如临时表
id是INT，但主表是BIGINT，某些版本 MySQL 会静默截断或拒绝匹配 - 临时表未提交：在事务中建临时表后，又执行了
ROLLBACK——临时表不受事务控制，但后续SELECT若在事务内，可能读不到刚插的数据（取决于隔离级别） - 大小写敏感问题：如果字段是
VARCHAR且 collation 为_cs（case sensitive），但插入值大小写和主表不一致，就匹配不上
替代方案对比：临时表 vs VALUES table vs 子查询
不是所有场景都适合临时表。选哪种，取决于数据来源、复用频率和 MySQL 版本。
-
VALUES ROW()（MySQL 8.0.19+）：适合一次性、小到中等规模（ - 子查询（
SELECT id FROM other_table WHERE ……）：适合 ID 来源本身就是数据库查询结果，且该查询能走索引；但若子查询本身慢，或优化器误判为相关子查询，性能反而更差 - 临时表：适合 ID 集合来自外部（如 API 请求体）、需多次复用、或数据量 >1000 的情况；唯一代价是多一次建表 + 插入，但换来的是确定性执行计划和可控索引
临时表不是银弹——它把问题从“SQL 解析瓶颈”转移到“IO 和插入延迟”，所以插入前务必评估数据量级和并发压力。一个常被忽略的点：tmpdir 磁盘空间和 max_heap_table_size 设置，会影响临时表是否落到磁盘，进而拖慢整个流程。
