MySQL大数据量IN查询性能优化：从秒级到毫秒级的五个手段-代码聚汇网

MySQL大数据量IN查询性能优化：从秒级到毫秒级的五个手段

黄芸芳·2026-08-31·阅读 24 GEO检测（免费）

MySQLIN查询性能优化

|难度：普通|阅读约 29 分钟

1. 为什么 IN 查询一到大数据量就原形毕露

1.1 一个真实案例：3000 个 ID 引发的 4 秒噩梦

先聊一个我自己项目里的真实场景。当时我们处理的是订单表，单表大概 8000 万行，业务方给过来一批订单号，要求批量查状态。第一次写出来的 SQL 很直白：

sql复制SELECT id, order_no, status, pay_time 
FROM order_info 
WHERE order_no IN ('PO202401010001', 'PO202401010002', ...);

那时集合里大概有 3000 个订单号，开发环境一跑，3 毫秒。上了预发环境，直接飚到 4.2 秒。当时第一反应是索引问题，检查后发现 order_no 上确实有唯一索引。那就奇怪了，有索引为什么还这么慢？

排查执行计划才发现，MySQL 对 IN 列表的优化方式是先把列表值排个序，然后根据索引去逐个二分查找匹配。索引本身没问题，问题出在 3000 次随机 IO、3000 次索引回表、再加上一次大集合的比较运算上。当列表元素从几十涨到几千，这个开销就不是线性增长，而是指数级翻倍。

这不是个别现象。IN 查询在开发环境小数据量时几乎看不出问题，一上生产、数据量一大、集合元素一多，立刻暴露。很多同学第一反应就是“加索引”“改 JOIN”，但实际业务里有些场景就是无法避免使用 IN，比如批量同步、批量审核、批量对账，数据源头就是个哈希集合或者一份外部文件，这时候更需要的是理解 IN 查询变慢的原理，然后对症下药。

1.2 执行计划背后的三个慢点

IN 查询大数据量慢通常由三个原因叠加造成：

第一个慢点是集合展开后的内部临时结构。 MySQL 优化器会把你写的 IN 列表展开成一个个常量条件，相当于把 SQL 变成了一长串 order_no = 'A' OR order_no = 'B' OR ...。如果 IN 里面有几千个值，这个条件树会非常庞大。优化器在评估执行计划时，对这些值做排序、去重、二分查找，这个过程本身就要消耗 CPU。在 MySQL 8.0 里，虽然这个处理方式比 5.7 有了改进，但集合数量大了之后，优化器对每个值做“等值判断”的成本依然不可小觑。

第二个慢点是索引命中后的回表行为。 就算 order_no 上有索引，InnoDB 的二级索引只存索引列和主键值。你要查 status、pay_time 这些非索引列，就必须通过主键回表到聚簇索引的数据页去取完整行。一个 IN 列表里的每个值，都对应一次索引查找 + 一次回表。按 3000 个值算，就是 6000 次左右的随机 IO，机械硬盘或者 IOPS 不高的云盘根本扛不住。

第三个慢点是临时表和排序开销。 如果查询里还带着 ORDER BY 和 LIMIT，MySQL 往往会先在内存中建立一个临时表，存放全部匹配结果，再排序、再取前 N 条。IN 匹配出的结果集本身就是大几千行，全量放进临时表再排序，内存不够就落到磁盘临时文件，这又是一轮设备 IO。

明白这三个慢点之后，优化方向就清晰了：压缩 IN 集合规模、减少回表、避免不必要的临时表排序。下面几条优化路径，都是围绕这三个根本问题来做的。

1.3 别再轻信“加个索引”这种万能答案

我在很多技术群里看到过一种说话方式：“SQL 慢了？加索引！”但 IN 查询慢，真不是加索引能解决的。

索引解决的是“无法快速定位”的问题，而大数据量 IN 查询慢的核心问题在于“单个索引访问次数太多”——索引本身是能命中的，但命中 3000 次和命中一次的成本天差地别。就算把索引建得再完美，也不会把 6000 次随机 IO 变成 2 次顺序 IO。

所以，与其把希望寄托在“万能索引”上，不如先老老实实看看这三个数据：

这个 IN 集合有多大，能不能压到几百以内；
每条 SELECT 是否需要回表，能不能用覆盖索引直接带回；
是否需要走临时表、排序、文件排序。

看完这三个数据，你大概率就知道了，自己应该走“拆批次”还是“改 JOIN”还是“加缓存”的路线。接下来的几个优化方案，我按照实际落地难易程度，从改 SQL 到改业务到改配置，一层一层说。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 最优先的思路：不碰 IN，但保留等价语义

2.1 临时表 + 连接：把大批量集合搬进数据库

如果 IN 集合过大是问题根源，最直接的办法就是“不把集合交给 SQL 优化器”，而是先把集合装进一张临时表，再用 JOIN 去连接。

实际做法是这样：先创建一个临时表，只要一个自增主键和一个 cid 字段，然后把那几千个 ID 分批插入临时表，插入完成后再执行关联查询：

sql复制CREATE TEMPORARY TABLE tmp_ids (
    id BIGINT PRIMARY KEY,
    cid VARCHAR(64) NOT NULL,
    KEY idx_cid (cid)
) ENGINE = InnoDB;

-- 这里用程序分批插入
INSERT INTO tmp_ids (cid) VALUES ('PO202401010001'), ('PO202401010002'), ...;

-- 用 JOIN 替代 IN
SELECT o.id, o.order_no, o.status, o.pay_time
FROM order_info o
INNER JOIN tmp_ids t ON o.order_no = t.cid;

这个方案的好处很明显：临时表上建了索引，JOIN 的关联查询会走一次索引的批量嵌套循环，MySQL 优化器对 JOIN 的执行计划优化成熟度远高于对超大 IN 集合的优化；而且临时表引用的数据是集中存储的，对于 InnoDB 的缓存和预读机制更友好。

有一个坑要提醒：临时表用完后必须 DROP，否则连接池里的连接如果复用，临时表会一直存在到会话结束。另外，大批量 INSERT 临时表本身也耗时，最好用批量 INSERT 或者 Load Data 方式。实测下来，3000 个值通过临时表方案，查询时间能从 4 秒降到 200 毫秒左右，效果立竿见影。

2.2 子查询与 semi-join：让优化器自己干活

有些业务场景下，IN 集合不是来自外部列表，而是来自一张已有的业务表。比如要查所有“已提交未支付且有效期大于今天”的订单，你可能会写成：

sql复制SELECT id, order_no, status
FROM order_info
WHERE order_no IN (
    SELECT order_no FROM order_archive WHERE expire_time > NOW()
);

这种写法在 MySQL 5.6 以后会触发 semi-join 优化。优化器会尽可能把子查询改写为半连接，然后走统一的 JOIN 执行策略，避免了逐值判断。

不过要注意一个细节：MySQL 的 semi-join 优化在子查询结果集特别大时不一定会启用，也会因为物化策略走一条不理想的路径。所以写完这条 SQL 后，最好配合 EXPLAIN 查看 Extra 列里是不是有 Start temporary、End temporary 或 Materialize 这样的关键字。如果看到 Full scan on IN 或者 Using where 且没有走索引，说明优化器放弃了 semi-join，那就要考虑用前面说的临时表方案强行走 JOIN。

2.3 什么时候可以保留 IN，什么时候必须拆

不是所有 IN 都要改。我的判断标准是三个维度：

集合元素数量：100 以内，索引命中良好，保留 IN 完全没问题；
表的数据量：如果表本身只有几万行，索引可有可无，IN 无压力；
查询列是否覆盖索引：如果 SELECT 的字段全在索引里，InnoDB 完全不用回表，那 IN 列表到 500 左右也没问题。

超过这个临界点，我建议直接改临时表方案，别等到线上 CPU 报警了再动手。尤其是集合数量上千、表数据量过千万的时候，保留 IN 等于按下了性能的定时炸弹。

3. 业务侧的大数据量集合拆分策略

3.1 分片批次的大小到底怎么定

很多业务场景不允许改 SQL 结构，那退而求其次的办法就是拆批。把 3000 个值的 IN 拆成 30 批，每批 100 个值，循环查询再在内存里做聚合。

分片大小不是随便定的。一般在 200 到 500 之间比较合适。太小的批次会导致循环次数过多、网络往返频繁，整体的 RT 反而会上去；太大的批次又回到了大数据量 IN 的老问题。

以 MySQL 8.0、SSD、单条查询平均耗时 50ms 为例，500 个 IN 值大约耗时 80ms 到 150ms，3000 个值拆 6 批，总耗时大概在 600ms 左右，还能接受。但如果你的数据库扛不住 6 次大查询，那才是真正的设计问题。

拆批的时候还建议错峰执行，不要用 CountDownLatch 一次性把 30 个查询全发出去，那样数据库连接池会瞬间被打满，其他业务跟着遭殃。用信号量控制并发度，一次最多 5 个线程同时查询，是最稳的做法。

3.2 用哈希字段把 IN 拆成可并行任务

如果业务场景允许，我们可以把问题从“数据库怎么处理大 IN”转成“怎么让每个 IN 都变小”。

一个实用技巧是按哈希字段拆分。比如订单表有 user_id，我们可以按 user_id 的哈希值分片。业务侧先把几千个订单号分组，每组的 user_id 落在一个哈希桶里，然后把每个桶对应的订单号作为一个小 IN 集合去查询。这样做的好处是每个小 IN 集合天然带有“均匀分布”的特性，数据在各个分片节点上更均匀，还能配合分库分表的策略。

如果表没有天然的哈希键，也可以自己生成一个。比如把主键 ID 对 16 取模，加一个逻辑上的分片字段。在数据写入时维护这个分片值，查询时按分片值拆批。这个方案对已有系统改造比较大，但对于新系统设计，是个值得考虑的长远解法。

3.3 缓存与预先计算：不给 IN 留机会

业务上很多“大数据量 IN 查询”其实是高频查询。比如用户给自己关注的 500 个商品批量查价格，这个查询可能每天被触发几十万次。这种场景下，没必要每次都打数据库，Redis 完全可以兜底。

做法是：把商品的实时价格预热到 Redis。用户访问时，先用 MGET 一次性取 500 个商品价格，MISS 的再回源数据库用 IN 查，然后回填。由于热点商品基本都覆盖了，MISS 率会很低，数据库压力大幅下降。

实测下来，这种方式能让 QPS 提升几十倍。所以说，优化不是只能盯着 SQL 本身，业务层缓存设计反而是性价比最高的“优化方案”。

4. 让数据库更抗造：执行器与临时表参数调整

4.1 tmp_table_size 与 max_heap_table_size：内存临时表够用才不落盘

刚才说 IN 查询带 ORDER BY 和 LIMIT 时，MySQL 可能会使用临时表。如果临时表先在内存中建，那一切好说；一旦超出内存限制，就会自动转为磁盘临时表。磁盘临时表的开销不仅是 IO，还可能导致执行计划中"Using temporary; Using filesort"出现，性能直线下降。

两个参数直接影响这种行为：

tmp_table_size：单张临时表的最大内存容量，默认 16MB；
max_heap_table_size：内存临时表的最大容量，默认 16MB，它会影响实际建表时采用的内存大小。

注意看，这两个参数是“取较小值”的关系。即便 tmp_table_size 设置了 64MB，只要 max_heap_table_size 还是 16MB，内存临时表也不会超过 16MB。

对于大数据量 IN 查询，如果结果集接近几万行、包含若干 VARCHAR 字段，16MB 很容易被撑爆。我建议把这两个值都调到 64MB 或者 128MB，然后观察进程内存和在 TempTable 上的压力。只有内存足够时才建议调大，否则会引发内存压力和数据页淘汰的连锁问题。

另外 MySQL 8.0 引入了 TempTable 存储引擎，通过 internal_tmp_mem_storage_engine=TempTable 启用，它比 Memory 引擎拥有更好的内存管理策略。如果你的版本是 8.0，建议开启这个配置。

4.2 覆盖索引、复合索引与 IN 的命中边界

核心目标是减少回表次数。如果 IN 查询结果集有 3000 行，覆盖索引可能把回表降到 0 次，效果立竿见影。

覆盖索引的创建思路是：尽量把 WHERE 中 IN 对应的字段和 SELECT 的所有字段都放到同一个二级索引里。比如一个查询：

sql复制SELECT id, order_no, status 
FROM order_info 
WHERE order_no IN (...);

那可以建一个复合索引：

sql复制ALTER TABLE order_info ADD INDEX idx_order_status (order_no, status, id);

这样查询可以完全通过这个二级索引拿到所有字段，InnoDB 不需要回表。实测在 3000 个 IN 值的情况下，覆盖索引能让查询时间缩短 40% 到 60%。

但索引不是越多越好。每个索引都会增加写入成本和存储空间，所以得权衡。我的原则是：只给最频繁的大 IN 查询建覆盖索引，低频查询没必要专门建。

复合索引在 IN 查询上还有一个陷阱：如果 IN 字段不是复合索引的最左前缀，索引是无法命中的。比如上面索引是 (order_no, status)，那 WHERE status IN (...) 就完全走不了这个索引。索引设计时，务必把 IN 字段放在最左边。

4.3 大 IN 遇上分页排序：深分页该怎么处理

之前有个朋友问我：一条 IN 查询结果有几万行，业务要按时间倒序排列，然后用户翻了几十页之后，SQL 慢到不可接受。这种“大 IN + 深分页 + 排序”组合拳，是最难优化的。

常规操作是 LIMIT 100000, 20，MySQL 会先找出所有符合条件的数据、排序、再丢弃前面的 100000 条，前面的数据全白查了。优化方式是“先取主键，再回表取详情”：

sql复制SELECT id, order_no, status, pay_time
FROM order_info
WHERE order_no IN (...)
ORDER BY pay_time DESC, id DESC
LIMIT 100000, 20;

改为：

sql复制SELECT id, order_no, status, pay_time
FROM order_info
WHERE id IN (
    SELECT id FROM (
        SELECT id FROM order_info
        WHERE order_no IN (...)
        ORDER BY pay_time DESC, id DESC
        LIMIT 100000, 20
    ) AS tmp
);

内层子查询只走覆盖索引，不回表，拿到 20 个主键之后，外层再用主键回表取完整数据。这样深分页的成本就从“几万行的排序 + 几万次的回表”变成了“几万行的索引扫描 + 20 次回表”。

这里再补充一种更优雅的方案：如果业务使用的是 MySQL 8.0，可以尝试用 ROW_NUMBER() 窗口函数来替代深分页：

sql复制SELECT id, order_no, status, pay_time
FROM (
    SELECT id, order_no, status, pay_time,
           ROW_NUMBER() OVER (ORDER BY pay_time DESC, id DESC) AS rn
    FROM order_info
    WHERE order_no IN (...)
) AS t
WHERE rn BETWEEN 100001 AND 100020;

窗口函数方案在结果集可控时表现不错，但结果集特别大时排序成本依旧存在，有时候不如“先主键后回表”直接。

5. 一次真实排查链路：从慢 SQL 抓取到方案落地

5.1 慢查询日志定位与火焰图思路

那次线上故障，我印象特别深。业务方反馈“订单列表接口慢慢慢”，监控面板一看，订单服务的 P99 延迟从 200ms 涨到了 3.8 秒，数据库 CPU 直接飙到 90%。我第一时间打开了慢查询日志：

sql复制SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1;
SET GLOBAL log_output = 'TABLE';

之后慢 SQL 会自动记录到 mysql.slow_log 表里，用这条查：

sql复制SELECT * FROM mysql.slow_log 
WHERE start_time > DATE_SUB(NOW(), INTERVAL 30 MINUTE)
ORDER BY query_time DESC 
LIMIT 10;

当场就抓到了那几条 order_no IN (...) 的大 SQL，执行时间 3.7 秒，扫描行数 12 万。然后我用 EXPLAIN 看了下执行计划，确认是范围扫描 + 回表。

如果还想看 MySQL 到底把时间花在哪个环节，可以用 performance_schema 去看语句阶段耗时。InnoDB 层的行锁等待、排序、临时表落盘都会体现在统计信息里。这一步做完，基本上就能把问题范围锁定到“索引回表太多”还是“临时表排序太慢”还是“连接等待太高”。

5.2 触发的三个问题：临时表落盘、MySQL 优化器走错索引、连接数被打满

这次故障里，我同时发现了三个问题，一个比一个麻烦。

第一个是临时表落盘。 慢 SQL 里带着 ORDER BY status DESC, pay_time DESC，MySQL 需要在内存临时表里排序 12 万行结果，超过 16MB 直接落盘，磁盘 IO 和排序时间叠加，查询慢得离谱。这在 SHOW STATUS LIKE 'Created_tmp_disk_tables' 这个计数器里能看到暴涨。

第二个是优化器走错索引。 订单表上既有 idx_order_no 唯一索引，也有 idx_user_id 普通索引。IN 查询本来应该走 idx_order_no 逐个匹配，但优化器根据基数估算，误以为 idx_user_id 的过滤性更好，结果选了 user_id 索引，再在临时表里去重 12 万行，整个执行计划错得离谱。这种问题用 FORCE INDEX 能强行修正，但治标不治本，不如把 SQL 改成 JOIN，让优化器的选择空间更小。

第三个是连接数被打满。 因为慢 SQL 把数据库 CPU 和 IO 都打满了，新请求连接等待时间变长，连接池里的线程全部阻塞，最终把 MySQL 的 max_connections 打满，前置服务开始连环报错。这时候如果你只顾着优化 SQL，压力会持续很久；应该先限制入口流量，让系统先恢复，再优化慢 SQL。

5.3 最终方案对比与回退预案

我做了三个方案的对比测试，都基于同一个 8000 万行的订单表：

方案	SQL 写法	单次查询耗时	数据库 CPU 占用	备注
原始 IN	`order_no IN (3000 个值)`	3.8s	高	回表 + 临时表
临时表 JOIN	临时表 + INNER JOIN	210ms	中	需分批插入临时表
覆盖索引 + 拆批	`IN (500 个值)` + 覆盖索引	85ms	低	应用层聚合

我最终选了“临时表 JOIN + 覆盖索引”的组合方案。逻辑是这样：先建临时表，把业务给的 3000 个订单号批量插入临时表；临时表上建订单号索引；主查询走 INNER JOIN 关联临时表和订单表；同时订单表侧预先建好了覆盖索引。这样既避免了 IN 集合太大，又让回表次数降到最低。

回退预案也很重要。因为临时表方案改动相对较大，上线前我保留了“按 500 个一组拆批 IN 查询”的方案作为开关。一旦新方案出现问题，比如临时表插入失败或连接池占用过高，可以直接切回拆批模式。这个降级开关在配置中心里用一句话就能切换。

6. 说点踩坑后的碎碎念

6.1 先做减法再做加法

优化 IN 查询的时候，很多人第一反应是“加”——加索引、加缓存、加机器。但我的经验是，先做减法：

减掉不需要的字段，避免回表到超宽行；
减掉不必要的排序，改成在应用层排序；
减掉重复的查询逻辑，能走缓存的绝不走库。

有一回我优化一条接口，数据库层面怎么调都到不了预期，后来发现业务代码里同一批订单号查了三次，每次都是同样的数据，只是通过三个不同的接口分别暴露。后来做了聚合查询，一次拿到全部数据，数据库压力直接减半。

6.2 监控指标里哪些能提前预警

吃过大亏之后，我把数据库监控里这几个指标加了告警：

Created_tmp_disk_tables：如果瞬时暴涨，说明有 SQL 频繁落盘；
Select_scan：全表扫描次数变多，往往是索引被优化器抛弃；
Innodb_buffer_pool_reads：磁盘读取次数高，说明缓存命中率在下降；
Threads_connected：连接数如果持续走高，可能是慢 SQL 在堆积。

这些指标如果能在问题发生前就发出预警，很多事故都是可以避免的。等用户反馈“慢”的时候，数据库往往已经受苦十几分钟了。

6.3 兜底不可少：限流与熔断

最后想提醒一句：查询优化得再好，也不能保证永远不会出问题。给查询加一层兜底保护很有必要。

比如在服务层面对“IN 集合大小”做硬校验——超过阈值就直接拒掉，或者强制走异步任务。接口层面做熔断——单条 SQL 执行超过 2 秒，直接抛错，不要让慢查询拖垮整个线程池。业务高峰期如果注定要做大数据量 IN 查询，就走离线任务，提前把结果算好，别让用户请求卡在数据库上等着。

数据库优化的尽头，永远不是把一条 SQL 调到极致，而是让系统在各种正常和异常情况下都能平稳运行。希望这篇的经验能帮你少踩几个坑。