clickhouse infoes

我们可以使用下面的查询来获取关于表的元数据：

SELECT
    part_type,
    path,
    formatReadableQuantity(rows) AS rows,
    formatReadableSize(data_uncompressed_bytes) AS data_uncompressed_bytes,
    formatReadableSize(data_compressed_bytes) AS data_compressed_bytes,
    formatReadableSize(primary_key_bytes_in_memory) AS primary_key_bytes_in_memory,
    marks,
    formatReadableSize(bytes_on_disk) AS bytes_on_disk
FROM system.parts
WHERE (table = 'hits_UserID_URL') AND (active = 1)
FORMAT Vertical;

 

带有联合主键(UserID, URL)的表的主索引对于加快UserID的查询过滤非常有用。但是，尽管URL列是联合主键的一部分，但该索引在加速URL查询过滤方面并没有提供显著的帮助。

反之亦然：具有复合主键(URL, UserID)的表的主索引加快了URL上的查询过滤，但没有为UserID上的查询过滤提供太多支持。

由于主键列UserID和URL的基数同样很高，过滤第二个键列的查询不会因为第二个键列位于索引中而受益太多。

因此，从主索引中删除第二个键列(从而减少索引的内存消耗)并使用多个主索引是有意义的。

但是，如果复合主键中的键列在基数上有很大的差异，那么查询按基数升序对主键列进行排序是有益的。

主键键列之间的基数差得越大，主键中的列的顺序越重要。我们将在下一章节对此进行演示。

开启客户端trace日志：

SET send_logs_level='trace';