交叉连接中的表顺序如何影响性能答案

【问题标题】：how order of tables in cross join affect performance交叉连接中的表顺序如何影响性能
【发布时间】：2019-01-22 22:41:29
【问题描述】：

我有 2 张桌子 A 和 B，它们都是 MergeTree 和 8192 index_granularity。当我将cross join 应用于 2 个表时。一般来说，查询喜欢

select
    count(*)
from
(select * from A where ... )
cross join
(select * from B where ...)
where ...;

原始表：A 有 314307856 记录，B 有 909470。
过滤掉：A 有 6599 记录，B 有 14860。（尽管记录差异很大，但两个过滤器都非常快）

我注意到在查询中切换A 和B 的顺序时性能存在巨大差距。

当A cross join B:1 rows in set. Elapsed: 12.242 sec. Processed 26.72 million rows
当B cross join A：1 rows in set. Elapsed: 45.584 sec. Processed 26.72 million rows

两个订单都有pipeline

CreatingSets
 Lazy
 Expression
  Expression
   ParallelAggregating
    Expression × (num_parts)
     Filter
      Expression
       Expression
        Expression
         Filter
          MergeTreeThread

有时候，B cross join A 有

CreatingSets
 Lazy
 Expression
  Expression
   Aggregating
    Concat
     Expression
      Filter
       Expression
        Limit
         Expression
          Union
           Limit × 7
            Expression
             Filter
              MergeTreeThread

--> 我注意到clickhouse-server 使用这条管道会很快耗尽我的记忆。

据我所知，使用join 查询，clickhouse 将首先执行右侧的执行，然后将其放入内存然后执行左侧。就我而言，过滤掉的A 和B 绝对适合内存。

我的问题是：

为什么 2 个查询的性能差异很大？ 2个表的顺序如何影响查询的性能？选择订单时的一些建议。
同一查询在多次执行中的管道可以不同吗？

更新 1：有关我的查询的更多详细信息

SELECT 
    count(*)
    FROM 
    (
          SELECT 
            ...
        FROM B 
        WHERE (((day >= '2018-08-15') AND (day <= '2018-08-16')) AND ((timestamp >= 1534310226442) AND (timestamp <= 1534399065648))) AND (log_time <= 1534316318187)
    ) 
    CROSS JOIN 
    (
      SELECT 
            ...
        FROM A
        WHERE (((day >= '2018-08-14') AND (day <= '2018-08-16')) AND ((timestamp >= 1534223826442) AND (timestamp <= 1534399065648))) AND (log_time <= 1534316318187) AND match(..., '...') 
    ) 
    WHERE position(..., ...) > 1

【问题讨论】：

请告诉我们WHERE 子句在做什么，因为您可能并没有真正进行交叉连接。
嗨。首先阅读关系数据库教科书的查询优化/实现章节。另请阅读minimal reproducible example 并采取行动。

标签： join clickhouse

【解决方案1】：

目前 ClickHouse 没有基于成本的优化器来自动交换表，如果它是实现相同结果的更有利的方式。首先存在这种差异的原因有很多，例如更好的处理器缓存利用率或在因为 WHERE 将其丢弃之前做额外的工作。性能自省功能目前正在合并到 ClickHouse master 中，并将在即将发布的版本中提供，目前深入挖掘主要限于普通的 linux 工具集，如 perf/strace/dstat/等。作为建议，您通过衡量最适合您的情况的方法做了绝对正确的事情，不要盲目相信任何人的建议。
ClickHouse 或多或少具有确定性，因此它不应该随着固定查询而改变。你能提供一种方法来重现这个吗？

【讨论】：