MySQL大IN查询性能优化：从原理到实践的完整方案

线上商城后台有个订单查询接口，运营人员从报表里复制出一批订单号，塞到IN条件里，一次查几千上万个订单的明细。上线后某个大促夜，这个接口直接把数据库的连接池拖满了，慢SQL日志里全是那条带几千个ID的IN查询，单次执行时间八九秒。当时第一反应是骂运营不会用系统，但冷静下来一想，这需求还真回避不了——业务侧就是需要按一批已知ID去批量捞数据。IN查询大数据量，在不少业务里是刚需，不是写SQL的人水平差。

这个题网上讨论不少，但多数是零散的“加个索引”“改JOIN”，真到自己动手时，你会发现每一条都有前提条件，没有一条是银弹。这篇文章我把自己这几年在MySQL里跟大IN查询死磕的过程——原理层面的、SQL改写层面的、参数层面的、架构兜底层面的——系统梳理一遍。内容主要面向后端开发、DBA和线上系统出过类似问题的运维同学，目标是看完之后你能根据自己业务的实际情况选对方案，而不是拿着别人的结论盲目抄。

1. 一个真实事故：几千个ID的IN查询拖垮接口

先说当时的现场。系统是典型的电商后台订单中心，MySQL 8.0，订单主表order_info有三千多万行，索引齐全，日常查询都在毫秒级。运营用的批量查询功能，逻辑很简单：接收一批订单号，拼成 IN 条件，去order_info表查出完整订单信息，返回给前端展示。本地测试时数据量小、压测也没问题，但大促期间运营手里的订单号列表动辄几千上万，这条SQL直接成了定时炸弹。

慢日志里抓到的SQL长这样：

sql复制SELECT *
FROM order_info
WHERE order_no IN
('A10001','A10002', ... /* 一共 9400 多个订单号 */)
ORDER BY create_time DESC;

执行计划打印出来，type是ALL，全表扫描，rows估算30万行，Extra里还带着Using filesort。这不是索引失效，是优化器在IN列表太长时压根没选择走索引。当时第一件事是把IN列表截短到500个做测试——执行时间从8.4秒降到了0.3秒。问题实锤了，但运营不可能手动拆分9000多个订单号去查，产品也不能说“查询上限500条”就算完事。

后来排查发现，这个慢还不只是全表扫描的问题。即使把SQL强改成FORCE INDEX(uk_order_no)让它走索引，单次查询也要2秒以上。原因很容易理解：9000多个订单号，每个订单号在辅助索引上命中的索引项，都要拿着主键ID去聚簇索引回表捞整行数据。回表是随机IO，9000次随机IO在机械盘上那就是灾难，SSD上虽然好一些，但高并发下一样扛不住。

那次的最终方案是分片查询——9000多个订单号切分成每批500个，串行查询，总耗时从8秒多降到2秒左右，再加一层Redis结果缓存，运营的体感提升非常明显。但这只是治标，治本还得从MySQL的执行机制去理解，为什么IN列表一大，性能就断崖式下跌。下面这节把底层原因拆开讲。

2. 为什么IN列表一大，性能就断崖下跌：从执行计划到回表成本

网上有句话流传很广：“IN查询不会导致索引失效。”这话对，但没有说到点子上。IN查询的问题从来不是“不能走索引”，而是“走了索引也很慢”，以及“优化器在特定条件下会放弃索引”。

2.1 优化器对IN列表的估算机制：eq_range_index_dive_limit是关键门槛

MySQL优化器对IN列表的处理，本质上是生成多个等值条件的OR展开，然后估算每个分支的基数，最后合并成一个执行计划。这里有个关键参数叫 eq_range_index_dive_limit，默认值是200。

它的含义是：当IN列表中的值个数不超过200时，优化器会对每个值真正去索引B+树里做一次“潜入式统计”（index dive），拿到精确的rows估算值；一旦超过200，优化器就不再逐个潜入，而是直接拿索引的统计信息去估算。索引统计信息是抽样出来的，碰到数据分布不均匀时，估算偏差会非常大。

比如某个订单号在索引里实际有几十条记录，但统计信息显示它只有1条，优化器就会觉得“走这个索引成本很低”，结果真实执行时发现每个值都要捞出大量行，还要挨个回表。反过来也可能把成本估高了，直接放弃索引走上全表扫描。后者就是我们线上看到的现象。

所以，当你看到一条大IN查询的执行计划变成ALL时，第一步不是急着加索引，而是先看一眼IN列表数量是不是超过了200。超过的话，调大eq_range_index_dive_limit只是一个可选项，但它会让每条SQL的解析阶段变慢，全局影响面很大，不能无脑调。

2.2 索引命中了，回表依然是大头成本

假设优化器已经正确选择了走索引，比如order_no上的唯一索引uk_order_no，那问题就全落在回表上。

做一次索引查询的路径是这样的：先在辅助索引B+树里定位到所有满足条件的叶子节点，拿到一批主键ID，然后再拿着这批ID去聚簇索引里查完整行数据。辅助索引本身的扫描是相对顺序的，但回表是按主键ID去聚簇索引里随机查找。主键ID在物理存储上并不连续，每回一次表都可能触发一次磁盘随机IO。

一次回表耗时大约在0.1ms到1ms之间，9000个ID就是0.9秒到9秒，这跟我们在线上观察到的结果基本吻合。更麻烦的是，回表操作是逐行执行的，MySQL的InnoDB引擎没法做批量预取，只能一行一行来。高并发场景下，这些回表请求还会把buffer pool里的热点页挤出去，连累其他正常查询。

2.3 排序字段没进索引，filesort雪上加霜

很多大IN查询的业务场景还会带ORDER BY排序。我们那条SQL就按create_time倒序排。如果这个排序字段没有索引，MySQL只能先把所有满足条件的数据找出来，放到sort buffer里做一次完整的排序操作。排序的数据量是几千行还行，但如果IN条件命中了几万行，sort buffer装不下，就会落盘生成临时文件，性能下降一个量级。

MySQL执行过程里有两个典型动作，一个是Using filesort，一个是Using temporary。这两个出现在大IN查询的执行计划里，基本可以断定这条SQL的耗时大头已经不在“查找”上，而在“排序和临时表”上。后面讲优化方案时，覆盖索引和索引设计就是专门解决这两个问题的。

2.4 子查询IN的坑：优化器可能比你想象的更笨

上面讲的都是IN列表直接给值的情况。还有一种是大IN查询极其常见的前置场景——子查询，比如：

sql复制SELECT * FROM order_info
WHERE user_id IN (SELECT user_id FROM blacklist WHERE status = 1);

MySQL对这种IN子查询的优化，并没有大多数人以为的那么聪明。旧版本里，它可能把外层表的每一行都代入子查询执行一次，也就是“相关子查询”的执行方式，效率非常低。5.6之后的版本引入了半连接优化，会把子查询结果物化成临时表，再跟外层表做半连接匹配，但物化临时表也得建索引、存数据、做匹配，全部是一笔开销。

大多数情况下，这类IN子查询改写成JOIN会有更好的表现，MySQL在JOIN里可以用驱动表去驱动被驱动表的索引查找，比物化整个子查询结果集再匹配要省得多。具体改写方法下面单独用一节讲。

3. 业务绕不开IN查询的场景：先给问题分个类

不是所有大IN查询都值得优化，也不是所有都该用同一种方案。动手之前先判断你踩的是哪一类，对症下药更高效。结合我见过的业务场景，大致能分四类。

第一类是“全字段查询型”，典型形态是后台管理功能里，从报表复制了一堆ID或编号过来查明细。这种查询要求返回完整行数据，SELECT *或者大字段全带上，回表成本几乎不可避免。优点是ID列表本身就是完整的，业务上不需要再做子查询。

第二类是“批量状态更新型”，比如一批订单号要统一标记为已发货、一批用户ID要批量加标签。这类一般是UPDATE语句带大IN，或者SELECT出来在业务代码里循环处理。它和查询型最大的区别是，很多时候可以用JOIN和临时表在一条SQL里完成，不需要先把数据捞出来。

第三类是“子查询结果驱动型”，IN列表不是直接给的，而是从另一张表或同一个表的子查询结果里来的。常见的有“找出最近30天有下单的用户”、“找出买过A商品的用户还买了什么”。这类问题的关键不在IN本身，而在子查询的结果集怎么物化、怎么匹配。

第四类是“深度分页/海量过滤型”，比如在一张大表上做多条件筛选，筛完还剩几万条ID，业务要分页展示，页码越深越慢。这种很多时候根本不该用SQL去翻页，而是该换搜索方案或者做游标式翻页。

我建议你先对号入座，能定位到具体类别后再看下面的优化方案。想只靠一条通用技巧解决所有场景的人，最终一般都会踩更大的坑。

4. 优化方案逐个拆解：从SQL改写到底层参数调优

先说明一下，这一节的方案优先级，是按改动成本从低到高、收益从高到低排的。实际落地时，你可以先从第4.1节的SQL改写入手，再逐步评估后面的方案。

4.1 方案一：IN子查询改JOIN，最直接有效

对于第三类“子查询结果驱动型”，把IN改JOIN基本是收益最高、风险最低的操作。用一个真实例子说明，这是某个后台权限系统里的核心查询：

sql复制-- 优化前：大IN子查询，查全部有权限查看订单的用户
SELECT *
FROM order_info
WHERE user_id IN (
  SELECT user_id FROM user_dept
  WHERE dept_id IN (1, 2, 3, 4, 5)
  AND status = 1
);

改写成JOIN：

sql复制SELECT o.*
FROM order_info o
INNER JOIN user_dept ud ON o.user_id = ud.user_id
WHERE ud.dept_id IN (1, 2, 3, 4, 5)
AND ud.status = 1;

关键区别在哪？第一条SQL的执行路径是：先把user_dept表里满足条件的user_id全部查出来，形成一个结果集；如果这个结果集很大，优化器很可能把它物化成临时表，再跟order_info做匹配；而order_info这边如果优化器选择全表扫描，那整个查询就是全部订单行和临时表做一次笛卡尔式匹配，代价巨大。

第二条SQL里，MySQL优化器会先确定驱动表。哪个表数据少哪个当驱动表，这里user_dept表满足条件的行可能只有几百，它会作为驱动表，每取一行都去order_info的user_id索引上做点查。访问路径从“扫描订单大表”变成了“只扫描几百行的小表，配合索引点查”，成本差别是数量级的。

任何一次IN子查询改写JOIN之后，都建议立刻EXPLAIN看一眼。重点看type列变成eq_ref或ref没有，Extra里还有没有Using where和Using temporary。

4.2 方案二：把大ID列表落地成临时表或中间表，本质是“以空间换时间”

第一类“全字段查询型”场景里，ID列表是显式给定的，没法用JOIN改写，因为根本没有第二张表。这时候最彻底的做法，是把几千个ID先灌进一张临时表或用业务逻辑生成一张中间表，加上索引，再JOIN主表。

MySQL里可以直接用临时表：

sql复制-- 1. 建临时表
CREATE TEMPORARY TABLE tmp_order_ids (
  order_no VARCHAR(32) PRIMARY KEY
) ENGINE=InnoDB;

-- 2. 批量插入ID列表（可以用程序批量insert，或者LOAD DATA）
INSERT INTO tmp_order_ids (order_no) VALUES
('A10001'), ('A10002'), ...;

-- 3. JOIN查询，强制走索引
SELECT o.*
FROM tmp_order_ids t
INNER JOIN order_info o ON t.order_no = o.order_no
ORDER BY o.create_time DESC;

临时表方案的优势非常明显：第一，JOIN能让优化器明确看到驱动表只有几千行，成本估算不会偏差；第二，临时表的order_no上建了主键索引，被驱动表的匹配是标准的ref，不会再有可怕的rows误判；第三，避免了IN列表展开带来的大量常数运算和语句解析开销。

中间表的思路类似，只不过不是会话级的临时表，而是建一张实表，批处理任务先写入ID，再关联查询。优势是数据可以复用，同一批ID多次查询时不用反复插入，劣势是要做数据清理，防止表无限膨胀。我一般建议：ID列表只在单次请求里用、会话结束就废，用临时表；ID列表要跨请求复用、是业务流程里的中间产物，用中间表。

4.3 方案三：分片查询，把大IN拆成小IN

这是最简单粗暴但极其有效的方法，也是我们线上那次事故最终采用的兜底方案。核心逻辑一句话：把几千个ID分摊成多个几百个ID的小批量，循环查询，最后在应用层合并结果。

以Java为例，核心代码大概这样：

java复制public List<Order> batchQuery(List<String> orderNoList) {
    List<Order> result = new ArrayList<>();
    int batchSize = 500;
    for (int i = 0; i < orderNoList.size(); i += batchSize) {
        List<String> subList = orderNoList.subList(i, Math.min(i + batchSize, orderNoList.size()));
        List<Order> part = orderMapper.selectByOrderNos(subList);
        result.addAll(part);
    }
    return result;
}

这里有几个关键经验：

• 单批大小不能拍脑袋定。我们当时在测试环境做了阶梯压测，500、800、1000、2000都试过，最后500毫秒级稳定且对数据库连接池友好。如果网络延迟高、数据库和应用不在同一机房，单批可以适当缩小到200到300。
• 每批查询的时间要监控起来。如果某一批突然变慢，说明这批ID里可能有严重数据倾斜，比如某个user_id下有几十万单，这时可以根据执行计划单独优化。
• 分批以后，业务层要对结果做去重。万一ID列表里有重复值，分批查回来可能重复，合并结果时用Map或者Set过滤一下。

分片查询看起来是“退回老办法”，但在很多业务里它是运维成本最低、风险最小的方案。你以为只能低端地循环？实际上，配合多线程（比如8个线程并发查不同批次）还能进一步压缩总耗时，但要注意连接池上限，别把数据库打满。我们先把串行跑通，稳定运行两周后，才上了线程池并发，最终总耗时降到1秒以内。

4.4 方案四：覆盖索引，绕回表的唯一正解

无论是IN子查询、JOIN还是临时表，只要是在大表上查完整行，回表成本都躲不掉。要彻底避开回表，只有一条路：让查询所需的所有列都包含在索引里，这就是覆盖索引。

比如上面那条订单查询，如果业务只需要订单号、用户ID、订单状态、创建时间四个字段，那就可以在order_info上建一个组合索引：

sql复制ALTER TABLE order_info
ADD INDEX idx_cover_order_no_status_time (order_no, user_id, order_status, create_time);

这样SQL改成：

sql复制SELECT order_no, user_id, order_status, create_time
FROM order_info
WHERE order_no IN (...)
ORDER BY create_time DESC;

整个查询就能在辅助索引上独立完成，不需要回表，也不需要filesort，因为组合索引已经把create_time也带上了，索引本身是有序的。Extra列会直接显示Using index，这是我们优化时最想看到的字样。

覆盖索引最适合那种查询字段固定的接口，比如列表页、详情页的某个独立模块。如果你的接口是SELECT *，想用覆盖索引就得把所有字段都塞进索引，那样索引体积会巨大，反而拖慢插入和更新，得不偿失。

4.5 方案五：eq_range_index_dive_limit调优，用好但不滥用

这个参数前面已经讲过原理。如果你的IN列表频繁超过几百个，而且你从执行计划里明确看到rows估算严重偏离实际（比如实际1万行，估算300行），那可以考虑把eq_range_index_dive_limit从默认的200调高。比如调到400或500，让优化器在IN列表不超过这个数量时做精确估算。

但有几个限制一定要清楚：

• 参数一旦调大，所有SQL的解析阶段都会变慢，因为每条IN查询都要做更多次的index dive。全局生效，不可能只对某一条SQL生效。
• 如果IN列表数量远超过设定值（比如设500但实际有5000），那依然会退化为基于统计信息的估算，这条参数救不了超大IN。
• 8.0版本里还有个配套参数optimizer_switch控制半连接和物化策略，比盲目调eq_range_index_dive_limit更精细，但也要靠EXPLAIN不断验证。

我一般把它当作一个组合拳里的辅助项，而不是主方案。主方案还是SQL改写和结构设计，实在不行才动全局参数。

4.6 方案六：数据治理兜底——归档、冷热分离、缓存

如果上面的方案都做完了，查询依然慢，那问题基本不在SQL层面，而在数据层面了。再好的执行计划，在几千万行的大表上做全行随机IO，天花板也很低。这时候要动的是架构和数据的脑筋。

第一招是冷热分离。订单等业务数据天然有冷热属性，把半年前的订单迁移到历史库，线上订单表只保留最近半年数据，大IN查询的扫描基数和回表页数直接减半。这是大促前DBA最喜欢干的事之一。

第二招是应用层缓存。大IN查询通常是运营、客服、管理后台这些低频系统在用，同一批ID反复查询的概率挺大。可以在Redis里缓存结果，KEY设计成ID列表的MD5，TTL设个10分钟，缓存命中时连数据库都不碰。不过阈值要控制好，比如ID超过5000就不走缓存只走数据库，避免超大KEY造成的内存浪费。

第三招是搜索引擎或OLAP引擎兜底。到了万级以上的ID列表和亚秒级响应要求，MySQL做起来已经心有余而力不足了。把订单数据同步到ES或者ClickHouse，用ES的terms query代替MySQL的IN，或者用ClickHouse的in子句在列式存储上扫，在特定业务场景里性能完全是另一回事。这等于引入了新的技术组件，成本高，但解决的数据量级问题也是前面所有方案都比不了的。

5. 用EXPLAIN和实测数据验证优化效果，别只靠感觉

任何优化方案上线前，都必须有两个东西：执行计划对比和压测数据。没有这两样，你没法说服自己，更没法说服团队和DBA。

5.1 看懂EXPLAIN里的四个关键信息

每次改了SQL，第一步就是EXPLAIN，四个字段重点看：

• type：最好的是eq_ref，其次是ref和range，ALL是灾难。我们优化的目标至少是range，最好是ref。
• key：实际使用的索引，NULL表示没走任何索引。
• rows：优化器估算需要扫描的行数。这个数越小越好，但如果明显偏离实际返回行数，可能是估算误差，也可能是走了统计信息而不是index dive。
• Extra：出现Using filesort要警惕，出现Using temporary要警惕，出现Using index要开心。

做个对比表格：

这个表是我摘取真实测试数据整理的，可以看到优化路径非常清晰：要么让rows降下来，要么让Extra里的坏味道消失，两者同时对是最好的。

5.2 同一数据集上的压测方法

EXPLAIN只是静态分析，真正上线前一定要做动态压测。方法不复杂，关键是控制变量。

准备同一批2000个ID的数据集，分别执行优化前后的SQL，记录三个指标：执行时间、逻辑读、物理读。在不用的MySQL客户端工具里都能看到这些信息，用SQL的话可以这样测：

sql复制SET profiling = 1;
-- 执行优化前的SQL
SELECT * FROM order_info WHERE order_no IN (...2000个ID...);
SHOW PROFILE;
-- 执行优化后的SQL（比如分批，循环执行）
SELECT * FROM order_info WHERE order_no IN (...第一批500个ID...);
SHOW PROFILE;

SHOW PROFILE能看到每个阶段耗时，最值得关注的是Sending data和Sorting result这两个阶段。Sending data时间长，说明回表和物理IO成本高；Sorting result时间长，说明排序成了瓶颈。

压测时还有一个容易被忽略的点：如果数据库服务器的buffer pool比较大，第一次执行时数据已经从磁盘加载到内存了，第二次、第三次再查可能快得离谱。所以压测要多轮循环，取稳定值，并且尽量在业务流量低峰期做，避免其他查询干扰。

5.3 慢查询日志和监控是最后的检票员

优化上线后，至少观察一周的慢查询日志，确认原来那条大IN SQL不再出现在日志里。我们当时是配置了监控告警，凡是执行超过1秒的SQL都触发邮件通知，线上问题秒级感知。

另外建议把数据库线程活跃数、连接池使用率也纳入监控。有时候SQL本身没慢，但因为大IN查询瞬时拉高了并发，导致其他正常查询排队，错误率上涨，这种间接影响比慢SQL日志更隐蔽，也更致命。

6. 落地时最容易踩的坑，写给你避雷

整个方案落地过程中，有五个坑是我亲身踩过或看过其他团队踩过的。写详细点，你们遇到类似问题时能少走弯路。

6.1 坑一：IN子查询无脑改JOIN，结果更慢

改JOIN不是万能的。有一种场景，子查询结果集非常小（比如几十行），IN本身已经走了半连接物化，改成JOIN反而可能因为驱动表选择不当，导致驱动表变成大表，扫描行数暴涨。所以每一次改写都必须EXPLAIN验证，不能因为网上说“IN改JOIN好”就不加分辨地搬。

6.2 坑二：临时表忘了加索引

把ID列表灌进临时表后，如果忘记在关联字段上建索引，后面那条JOIN的执行计划会出大问题。临时表数据量几千行，在主表数据没索引时可能触发大表全扫描，性能比原版大IN还差。建临时表时直接把关联字段设置为PRIMARY KEY，通常是最省事的做法。

6.3 坑三：分片查询里事务范围没控制好

分片查询在应用层循环执行时，如果每批查询都放在同一个事务里，事务会持有一堆行锁和undo日志，时间一长连接就卡在事务里。尤其UPDATE语句的分片执行，大批量更新要特别注意事务边界。我一般建议每批一个事务，或者干脆用自动提交模式，避免一个长事务拖垮整个连接池。

6.4 坑四：覆盖索引字段顺序设计错了

覆盖索引不是把所有查询字段都塞进去就算完。顺序有讲究：等值条件字段放最前面，排序字段放中间，投影字段放后面。比如上面那个例子，等值条件是order_no，排序是create_time，所以建立索引时把这两个字段放前面，最后才带user_id和order_status。顺序搞反了，排序字段无法利用索引有序性，Using filesort照样出现，覆盖索引的好处就丢了一半。

6.5 坑五：只优化SQL不动数据，迟早会再翻车

这是最核心的一点认知。SQL优化解决的是同一数据规模下的效率问题，数据规模一旦继续膨胀，SQL再怎么写也无济于事。我们当时优化完那条接口，稳了大概三个月，后面订单量又涨了一倍，分片查询的总耗时开始坐火箭。最后是上了历史订单归档才真正把问题压住。所以，任何一个大IN查询的优化方案，都要同时想清楚“数据量涨到两倍时怎么办”，归档策略、冷热分离这些数据治理手段，要从一开始就纳入规划。

7. 一点个人体会

回过头看这个大IN查询的优化，本质上是在“数据库计算能力”和“业务复杂查询需求”之间做平衡。很多开发者的第一反应是抱怨业务逻辑不合理，但实际上，像批量ID查询这种操作，在真实业务里就是没法避免的。与其硬刚SQL写法，不如把思路放宽：改SQL、加索引、做缓存、调整数据分布、甚至换存储引擎，每一步都有它适合的舞台。

如果只让我留一条经验，那就是：任何一个优化方案，都必须在你自己的数据量级、并发模型和业务特性下重新验证一遍。网上方案是用来参考的，不是用来照搬的。希望这篇文章能给正在被大IN查询折磨的你提供一个系统性的排查思路。如果你试完还有更极端的案例，欢迎来交流，我也很好奇你们是怎么做的。