我遇到问题时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')
;
if there are few values output is following, which is ok
but if IN ('0','649','650','651','652','653','654','655', thousand values)查询运行约 1 分钟并解释对此的更改
如何解决这个问题？
UPDATE: range_optimizer_max_mem_size had already set to 0 and isn't issue
当有人运行一个包含很长的值列表的查询时，我们在我的公司遇到了类似的问题。IN (...)谓词。
我们发现 MySQL 对范围优化器可用的内存强制实施限制。如果值列表太长，则超出了内存限制，优化器无法完成其分析以查看是否应该使用索引。所以它放弃了，并说：“算了！这只是为你做的表扫描。”
我们通过设置 MySQL Server 配置值来修复它range_optimizer_max_mem_size=0这意味着范围优化器可以使用的内存没有限制。
这会产生一个风险，如果有人要运行一个包含一百万个值的查询IN (...)列表中，它可能会使用大量内存，也许足以杀死 MySQL 服务器。但到目前为止，这种权衡是更好的，允许优化器选择索引。
请参阅文档：
回复您的评论：
优化器选择执行表扫描的另一个常见原因是，它计算出您的条件与表的足够大的部分相匹配，因此使用索引比简单地运行表扫描并检查每一行的成本更高。
此阈值没有记录，它取决于基于成本的优化器的实现，因此它可能会因版本而异。但我的观察是，通常如果您的条件与表的 20% 以上匹配，优化器就会选择表扫描。
你可以使用索引提示告诉优化器将表扫描视为无限昂贵，因此索引优于表扫描。