MySQL:索引合并排序-联合访问算法是否使用临时表？

Question

我的问题是index_merge在MySQL中的优化。

我有一个查询，其中包含一组与OR相关的范围条件。对查询的解释显示使用了index_merge方法，而额外的列只包含：

'Using sort_union({list of merged indexes}); Using where'

问题是：“此查询是否使用临时表？”

在“8.2.1.4.3索引合并排序-联合访问算法手册”的MySQL部分中，这样写道：

排序-并算法和联合算法的区别在于，排序联合算法必须首先获取所有行的行ID并在返回任何行之前对它们进行排序。

看起来RDBMS将使用一个临时表。但在8.4.4 MySQL如何使用内部临时表一节中，我们可以读到：

要确定查询是否需要临时表，请使用EXPLAIN并检查额外的列，以查看它是否表示使用临时表(参见8.8.1节，“优化查询与解释”)。“解释”不一定说对派生表或物化临时表使用临时表。

但在本例中的额外列中没有“使用临时”一栏。查询中没有子查询或联合。查询如下：

SELECT *
FROM A
JOIN B USING(pk)
WHERE (B.c1 IN ({list_of_values}) OR B.c2 IN ({list_of_values}) OR ... OR B.c9 IN ({list_of_values})) AND {some_other_conditions};

在INDEXes上有9列B.c1，B.c2，.，B.c9列.

Answer 1

我进行了一个实验:将查询从在单个查询中使用9个OR重写为由9个子查询组成的UNION。正如预期的那样，在最后一行中对重写的查询进行解释: select_type = "UNION“，Extra = "Using”。这样的更改是为了拥有一个使用临时表进行比较的查询。

现在，当我使用这个查询的原始形式(9个of )启动一个应用程序时，每个检查Created_tmp_tables只增加1(从手动:调用显示状态会使全局Created_tmp_tables值增加1)。

当我使用重写查询启动应用程序时，Created_tmp_tables增长很快。

我认为这个实验足以说明在index_merge Sort的情况下没有创建临时表。

结论:不，它不是。