Mysql查询的工作时间是200 or，选择in (xx，xxx，xx)中有33594个参数，但在33595或更多参数下运行几个小时，为什么？

Question

我们有一个小故障，为一个设备产生了意想不到的数据量。我们的代码在XXX创建了一个SELEXT *这样的SELEXT*查询，其中yyy (xxx，xxx，xxx.，xxxx)应该获取最后5天的数据，这通常不是问题，因为WHERE字段是索引的。

我们突然开始有大量缓慢的查询，并使服务器陷入困境。在我们中止查询之前，这些查询的运行时间大约为5000秒。如果我们在IN ()子句中有最多33594个参数的查询，那么每件事情都可以正常工作，查询在200 it内完成。如果我们添加一个参数，select似乎将永远运行。在它完成之前，我们还没有让它不确定地运行，所以我不确定它是否会完成，但它们似乎至少持续了几个小时。

select中的数据大约为361.04KB。我们在Google上运行MYSQL MYSQL_8_0_31

对造成这种行为的原因有什么想法吗？

Answer 1

在我的公司，从MySQL 5.7开始，我们就遇到了问题，根据选项range_optimizer_max_mem_size，优化器可以使用的内存有一个上限。如果列表中有太多项，优化器将放弃，并决定进行表扫描而不是使用索引。

请参阅https://dev.mysql.com/doc/refman/5.7/en/range-optimization.html#range-optimization-memory-use

我们的解决方案是在my.cnf中设置它：

range_optimizer_max_mem_size=0

这意味着优化器没有内存限制，所以应该由开发人员来避免列表太长，从而导致内存错误。但它更有可能使用指数。

这解决了每个长列表导致表扫描的情况下的问题。