MySQL的IN子句无1000项硬限制，实际受限于max_allowed_packet、内存开销及索引失效风险；超长时应分批（推荐500~999个/批）或改用临时表+EXISTS优化。
MySQL的IN子句根本没有“1000个”硬限制
很多人一看到MySQL IN list is too long就以为是数据库设了死规矩，其实不是。MySQL官方文档里压根没写“最多1000个值”——这个数字只是某些版本中优化器成本估算的拐点：当IN列表太长时，优化器可能觉得“走索引扫描不如全表扫快”，于是主动放弃索引。真正卡住你的，是三样东西：max_allowed_packet（SQL长度）、内存开销、以及索引失效风险。
报错Packet for query is too large怎么修？
这是最常撞上的墙，本质是拼出来的SQL字符串超长了。比如传1万个ID进IN，光括号里的数字加逗号就轻松破几MB。
-
max_allowed_packet默认通常是4MB或16MB，查当前值用SHOW VARIABLES LIKE 'max_allowed_packet'; - 临时调大可以救急：
SET GLOBAL max_allowed_packet = 64*1024*1024;（64MB），但别长期这么干——大SQL会吃光Buffer Pool，挤掉热点数据缓存 - 更稳妥的做法是：在应用层控制单次
IN不超过500~999个值（避开Oracle兼容性坑），靠分批解决
分批查询时该选500还是1000？
不是越大越好，也不是越小越稳，得看你的数据特征和并发压力。
- 如果主表
id字段有主键或唯一索引，500~999都行；但若字段只有普通索引且选择性差（比如status IN (0,1)），哪怕只放10个值也可能触发全表扫描 - 高并发场景下，每批1000个值 × 100个并发 = 瞬间10万连接请求，容易打满连接数或触发
net_buffer_length溢出；这时宁可降成300~500个/批 - Java里用
Lists.partition(ids, 500)，Python用[ids[i:i+500] for i in range(0, len(ids), 500)]，别手写循环边界
什么时候该换临时表而不是分批？
当你要查的ID列表稳定、复用率高，或者单次要查上万甚至十万级ID时，分批的网络往返和连接开销反而更大，临时表更优。
- 必须用
CREATE TEMPORARY TABLE（不是普通CREATE TABLE），否则多个请求会冲突；临时表生命周期随连接结束自动销毁 - 插入时用
INSERT INTO temp_table VALUES (1),(2),(3)...批量写入，比逐条INSERT快一个数量级 - 关联时优先用
EXISTS而非JOIN：因为EXISTS能短路（找到第一个匹配就停），而JOIN会生成笛卡尔积中间结果，内存爆得更快
真正容易被忽略的点是：IN列表大小不是孤立问题，它和索引质量、字段选择性、并发模型绑在一起。你调大max_allowed_packet后没报错，但查询变慢了——大概率是优化器弃用了索引。这时候该看EXPLAIN里的type是不是从range退成了ALL，而不是继续堆参数。
