MySQL含大列表IN条件的WHERE查询是否会转为全表扫描？

表A的ObjectId字段已创建索引，使用如下语句查询：

SELECT * FROM `A` AS a WHERE `a`.`objectId` IN ('00017a41-1ac0-4775-822b-de00cfd5902d', '000216dc-03cb-4e73-8177-3c2e49bc6622', '00035b33-2a62-464a-817b-6e23e8961bce')

测试时IN列表值数量较少，EXPLAIN显示会使用ObjectId索引；但实际场景中IN列表超过30000个值时，mysql.slow_log显示扫描近900万条记录，仅返回约32000条，疑似执行了全表扫描。由于用Workbench测试大列表的EXPLAIN会崩溃，故咨询：

• 是否存在索引使用的数量阈值，超过后转为全表扫描？
• 或是对慢日志的扫描记录数理解有误？

• 确实存在动态的执行计划切换逻辑
  MySQL优化器会基于成本估算选择执行方式：当IN子句中的值数量过多时，优化器会判断“通过索引逐个查找匹配值”的累计成本（包括多次索引IO、CPU开销）高于“全表扫描后过滤”的成本，就会放弃使用索引，转而执行全表扫描。这个阈值没有固定数值，是优化器结合表数据量、索引区分度、服务器资源等因素动态计算的，数万级别的IN列表很容易触发这个切换。

• 慢日志的扫描记录数理解正确
  慢日志中的rows_examined字段就是执行过程中实际读取的行数，全表扫描时该数值会接近表的总数据量，和你看到的“扫描近900万条”情况吻合，说明确实走了全表扫描。

• 可行的替代方案

  • 将IN列表的值存入临时表，用JOIN替代IN子句：比如创建临时表tmp_ids并插入所有目标objectId，再执行SELECT a.* FROM A a JOIN tmp_ids t ON a.objectId = t.id，这种方式优化器更易选择索引关联查询。
  • 拆分大IN列表为多个小批量查询：比如每次查询5000个值，再合并结果，每个小查询都会稳定使用索引。

内容的提问来源于stack exchange，提问作者Ben