在应用LIMIT（clickhouse）之前对子查询进行SELECT计数

Question

我有一个聚合了一些UNION ALL选择的子查询。在此之前，我准备了SELECT来创建交叉表并将其限制为20.我希望能够在主查询中限制它们之前检索子查询结果的总计数。这是为了尝试构建一个分页，它接收记录的总数，然后是特定的页面记录网格。

样品查询：

SELECT 
    name, 
    sumIf(metric_value, metric_name = 'data') AS data, 
    sumif(.... 
FROM 
    (SELECT 
     name, metric_name, SUM(metric_value) as metric_value 
    FROM 
     (SELECT 
       name, 'data' AS metric_name, SUM(data) AS metric_value 
      FROM 
       table 
      WHERE 
       date > '2017-01-01 00:00:00' 
      GROUP BY 
       name 

      UNION ALL 

      SELECT 
       name, 'data' AS metric_name, SUM(data) AS metric_value 
      FROM 
       table2 
      WHERE 
       date > '2017-01-01 00:00:00' 
      GROUP BY 
       name 

      UNION ALL 

      SELECT 
       name, 'data' AS metric_name, SUM(data) AS metric_value 
      FROM 
       table3 
      WHERE 
       date > '2017-01-01 00:00:00' 
      GROUP BY 
       name 

      UNION ALL 

      . 
      . 
      .) 
    GROUP BY 
     name, metric_name) 
GROUP BY 
    name 
ORDER BY 
    name ASC 
LIMIT 0,20; 

第一个子查询返回大量数据的，所以我想我可以指望它并返回作为一个列值，或行，它会传播到主选择限制20个结果。因为我需要知道整个结果集，但不希望两次调用同一个查询而没有限制，仅限于获取COUNT。至少有12个UNION ALL三级子选择，为什么浪费资源。我期待尝试通用SQL解决方案不一定与ClickHouse

我想使用count(*) OVER()，但不支持，所以如果这只是选项，我知道我需要运行查询两次。

Answer 1

应该提到的第一件事是，没有人通常对查询的确切页数感兴趣。它可以很容易地估计，几乎没有人会关心估计的确切程度。但是，如果您有一个链接到GUI中的最后一页，人们通常会点击链接来查看它是否有效。

尽管如此，有些情况下分析人员应该访问所有页面，然后GUI应显示确切的工作量。好消息是，在后一种情况下，更好的策略是缓存整个结果表的快照并计算表中的行不再成为问题。

我的意思是，与客户讨论他们是否真的需要它是有意义的，因为每天多次不必要的全面扫描可能会影响数据库负载和计费总额。

无论如何，如果您仍然需要估计行数，您可以简化查询以计算行数。据我所知，这是一样的东西：

SELECT SUM(cnt) as row_count 
FROM (
    SELECT COUNT(DISTINCT name) as cnt FROM table1 WHERE date > ... 
    UNION ALL 
    SELECT COUNT(DISTINCT name) as cnt FROM table2 WHERE date > ... 
    ... 
) as counts; 

，或者如果data是恒定的指标名称

SELECT COUNT(DISTINCT name) as row_count 
FROM (
    SELECT DISTINCT name FROM table1 WHERE date > ... 
    UNION ALL 
    SELECT DISTINCT name FROM table2 WHERE date > ... 
    ... 
) as names;