当我的查询在“IN”子句中有大量值时，MySQL 不使用我期望的索引

问题描述

当 IN 子句包含太多值时，我遇到了问题。考虑这个查询

EXPLAIN
SELECT DISTINCT t.entry_id,t.sticky,wd.field_id_104,t.title
FROM exp_channel_titles AS t
LEFT JOIN exp_channels ON t.channel_id = exp_channels.channel_id
LEFT JOIN exp_channel_data AS wd ON t.entry_id = wd.entry_id
LEFT JOIN exp_members AS m ON m.member_id = t.author_id
INNER JOIN exp_category_posts ON t.entry_id = exp_category_posts.entry_id
INNER JOIN exp_categories ON exp_category_posts.cat_id = exp_categories.cat_id
WHERE t.entry_id !=''
  AND t.site_id IN ('1')
  AND t.entry_date < 1610109517
  AND (t.expiration_date = 0 OR t.expiration_date > 1610109517)
  AND t.entry_id  IN ('0','649','650','651','652','653','654','655')
;

如果输出的值很少，那没关系

但是如果 IN ('0','655',thousand values) 查询运行大约 1 分钟并解释对此的更改

如何解决这个问题？

更新：range_optimizer_max_mem_size 已经设置为 0 并且不是问题

解决方法

当有人在 IN (...) 谓词中使用很长的值列表运行查询时，我们公司也遇到过类似的问题。

我们发现 MySQL 对范围优化器的可用内存实施了限制。如果值列表太长，则超出内存限制，优化器无法完成其分析以查看是否应使用索引。所以它放弃并说：“算了！这是对你的表扫描。”

我们通过设置 MySQL 服务器配置值 range_optimizer_max_mem_size=0 来修复它，这意味着范围优化器可以使用的内存没有限制。

这会产生一个风险，如果有人要使用 IN (...) 列表中的一百万个值运行查询，它可能会使用大量内存，可能足以杀死 MySQL 服务器。但到目前为止，权衡是可取的，允许优化器选择索引。

查看文档：

• https://dev.mysql.com/doc/refman/5.7/en/range-optimization.html
• https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_range_optimizer_max_mem_size

---

重新评论：

优化器选择进行表扫描的另一个常见原因是它计算出您的条件匹配表的足够大的部分，因此使用索引比简单地运行表扫描并检查成本更高每一行。

此阈值没有记录，它取决于基于成本的优化器的实现，因此它可能会因版本而异。但我的观察是，通常如果您的条件匹配表的 20% 以上，优化器会选择 table-scan。

您可以使用 index hint 告诉优化器将表扫描视为无限昂贵，因此索引优先于表扫描。

,

爆炸-内爆。这是编写查询的低效方式的经典问题。

1. JOIN 几张表
2. 过滤器
3. 折叠结果——通常用 GROUP BY 或 LIMIT，但 DISTINCT 具有相同的效果。

所以...把查询翻过来。

1. 在 t

   中查找所需行的 ID

2. JOIN 其他表格。

3. 大概根本不需要 DISTINCT。

    SELECT  t2.entry_id,t2.sticky,wd.field_id_104,t2.title
        FROM ( SELECT id
             FROM  exp_channel_titles
             WHERE entry_id !=''
              AND site_id IN ('1')
              AND entry_date < 1610109517
              AND (expiration_date = 0 OR expiration_date > 1610109517)
              AND entry_id  IN ('0','649','650','651','652','653','654','655')
             ) AS t
        JOIN exp_channel_titles AS t2  USING(id)
        LEFT JOIN  exp_channels  ON t2.channel_id = exp_channels.channel_id
        LEFT JOIN  exp_channel_data AS wd  ON t2.entry_id = wd.entry_id
    ;
   

另一种形式化

由于 md 只有一种用途，所以这可能更好：

SELECT  entry_id,sticky,( SELECT wd.field_id_104
            FROM exp_channels  ON t2.channel_id = exp_channels.channel_id
            LEFT JOIN  exp_channel_data AS wd  ON t.entry_id = wd.entry_id
        ) AS field_id_104,title
    FROM  exp_channel_titles
    WHERE entry_id !=''
      AND site_id IN ('1')
      AND entry_date < 1610109517
      AND (expiration_date = 0 OR expiration_date > 1610109517)
      AND entry_id  IN ('0','655')
;

并有一个 5 列索引 以 site_id,entry_date

开头

其他...

AND (t.expiration_date = 0 OR t.expiration_date > 1610109517)

OR 不是 sargeable。您能否重新设计表格以避免出现这种OR？

如果没有上述重新表述，这可能会有所帮助：

INDEX(site_id,entry_date)

另外，去掉这些，因为它们似乎完全没用：

LEFT JOIN exp_channels ON t.channel_id = exp_channels.channel_id
LEFT JOIN  exp_members AS m  ON m.member_id = t.author_id

而这些可能没用：

    INNER JOIN  exp_category_posts  ON t.entry_id = exp_category_posts.entry_id
    INNER JOIN  exp_categories  ON exp_category_posts.cat_id = exp_categories.cat_id