MySQL对IN子句无内置数量限制，真正限制是max_allowed_packet；该参数控制整个SQL包字节长度，需同步调整会话级、客户端及net_buffer_length；超2000值易致优化器失效，应优先用VALUES、临时表或分批查询。
MySQL 解析器本身对 IN 子句没有内置数量限制 —— 真正卡住你的，是 max_allowed_packet。
为什么改了 max_allowed_packet 还报 “Packet for query is too large”？
这个错误不是解析器拒绝 IN，而是 MySQL 服务端在接收完整 SQL 包时发现它超出了 max_allowed_packet 设置值。注意：该参数控制的是「整个查询语句」的字节长度，不只是 IN 里的值。
常见误判点：
-
max_allowed_packet是会话级 + 全局级双生效的，只改全局（SET GLOBAL max_allowed_packet = 67108864）不等于当前连接能用，必须重连或显式SET SESSION - 客户端（如 MySQL CLI、JDBC、Python 的 pymysql）也有自己的缓冲区限制，比如 JDBC 的
maxAllowedPacket参数需同步调大 -
net_buffer_length（默认 16KB）会影响初始分包，虽会自动扩容，但过小会导致频繁 realloc，间接触发超时或截断
IN 列表实际能塞多少个值？看字节数，不是看个数
假设你要塞的是整型 ID：id IN (1,2,3,...,N)，每个数字平均占 5–10 字节（含逗号、空格、括号），那在默认 max_allowed_packet=4MB（4194304 字节）下，理论极限约 40 万～80 万个值 —— 但这只是纯计算，现实根本不能这么用。
真正该关注的不是“最多多少”，而是“多大会出问题”：
- 超过 2000 个值时，MySQL 5.7+ 的优化器可能跳过索引 dive，转而依赖统计估算，导致执行计划劣化（
eq_range_index_dive_limit默认 200） - IN 列表过大 → 解析阶段内存开销飙升 → 容易触发
Out of memory或被oom_killer干掉（尤其在低配容器环境） - 即使语法通过、查询跑通，无索引字段上用 10 万个值的
IN，等价于全表扫描 + 内存哈希匹配，CPU 和 I/O 压力直接拉满
调整 max_allowed_packet 是治标，不是解法
盲目调大这个参数，只会把问题从“SQL 被拒”推迟到“查询慢炸”或“服务夯住”。生产中更应做的是规避大 IN 场景：
- 有主键/索引字段查大批量 ID？优先走
VALUES子句（MySQL 8.0.19+）：SELECT * FROM t JOIN (VALUES ROW(1), ROW(2), ... , ROW(N)) AS v(id) USING(id) - 不支持
VALUES？建临时表 +JOIN，比拼接长IN更稳定、可复用、易监控 - 必须用
IN？按 500～1000 个值一批拆分，用应用层并发或串行执行，加UNION ALL合并结果（注意避免过多连接占用）
最常被忽略的一点：哪怕你把 max_allowed_packet 设成 1GB，只要 IN 对应的字段没索引，查询就仍是全表扫描——此时限制你的从来不是字节长度，而是磁盘 I/O 和内存带宽。
