MySQL in 太多出现慢的原因

在MySQL中有一个配置参数eq_range_index_dive_limit，它的作用是一个等值查询(比如：in 查询)，其等值条件数小于该配置参数，则查询成本分析使用扫描索引树的方式分析，如果大于等于该配置参数，则使用索引统计的方式分析。使用扫描索引树的方式分析在MySQL内部叫做index dives，使用索引统计的方式分析在MySQL内部叫做index statistics。

eq_range_index_dive_limit 默认值是 200 .

select * from dogs where id in (1, 2, 3, 4);

结合上面这条 SQL，就是如果 SQL 中 IN 查询字段 id 的值出现的数量小于 eq_range_index_dive_limit，则走索引树扫描分析查询成本，大于等于 eq_range_index_dive_limit，则走索引统计的方式分析查询成本。

扫描索引树的方式分析 SQL 的查询成本，它的好处就是在 IN 查询的值数量不多时，得到的成本结果是精确的，这就意味着 MySQL 可以选择正确的执行计划，保证语句查询的性能。你现在一定有个疑问：为什么说是在 IN 查询的值数量不多时才是精确的，因为扫描性能的原因，MySQL 在 IN 查询的值数量很多的情况下，扫描索引树成本提高，性能下降，导致查询成本分析代价也随之提高了。

索引统计的方式分析 SQL 的查询成本，由于无需扫描索引树，所以，它的优势就是查询成本分析过程快，代价低。但是，它的缺点也很明显，由于无需扫描索引树，通过粗略统计索引使用情况，得出查询成本，导致 MySQL 可能选错执行计划，使得 SQL 查询性能下降。

解决方案

方案一

可以通过拆分 in 的数量, 分批查询.

select * from table where id in (1, 2);

select * from table where id in (3, 4);

这种方法缺点也明显, 对于分页或者是查询总条件的一部分并不能实现.

方案二

使用 union all 实现内存级别临时表.

select *
from table
where created > '2020-01-01' 
and id in ( '1' ,'2','3' ....'1000个');

select * from table t
inner join (select -99 as id union all select '1' union all select '-1'
union all select '1' ) as temp on t.id = temp.id
where created > '2020-01-01'

结果: 在 383 ms (execution: 201 ms, fetching: 182 ms) 内检索到从 1 开始的 500 行