查询条件缓存

注意

查询条件缓存只有在 enable_analyzer 设置为 true 时才有效，默认值为 true。

许多实际工作负载涉及对相同或几乎相同的数据进行重复查询（例如，先前存在的数据加上新数据）。ClickHouse 提供了各种优化技术来优化此类查询模式。一种可能性是使用索引结构（例如，主键索引、跳过索引、投影）或预计算（物化视图）来调整物理数据布局。另一种可能性是使用 ClickHouse 的查询缓存以避免重复查询评估。第一种方法的缺点是它需要数据库管理员进行手动干预和监控。第二种方法可能会返回陈旧的结果（因为查询缓存在事务上不一致），这取决于用例，可能可以接受也可能不可接受。

查询条件缓存为这两个问题提供了一个优雅的解决方案。它基于这样的理念：在相同的数据上评估筛选条件（例如，WHERE col = 'xyz'）将始终返回相同的结果。更具体地说，查询条件缓存会记住每个评估的筛选条件和每个粒度（默认情况下，粒度 = 8192 行的块）是否没有行满足筛选条件。该信息记录为单个比特：0 比特表示没有行匹配筛选条件，而 1 比特表示至少存在一个匹配行。在前一种情况下，ClickHouse 可以在筛选评估期间跳过相应的粒度，而在后一种情况下，必须加载和评估该粒度。

如果满足三个先决条件，查询条件缓存才有效

首先，工作负载必须重复评估相同的筛选条件。如果查询被多次重复，则自然会发生这种情况，但如果两个查询共享相同的筛选条件，例如 SELECT product FROM products WHERE quality > 3 和 SELECT vendor, count() FROM products WHERE quality > 3，也可能发生这种情况。
其次，大部分数据必须是不可变的，即在查询之间不会发生变化。这通常是 ClickHouse 的情况，因为部分是不可变的，并且仅由 INSERT 语句创建。
第三，筛选条件必须具有选择性，即只有相对较少的行满足筛选条件。匹配筛选条件的行越少，记录为比特 0（不匹配的行）的粒度就越多，并且可以从后续筛选评估中“剪除”更多数据。

内存消耗

由于查询条件缓存仅存储每个筛选条件和粒度的一个比特，因此它仅消耗少量内存。可以使用服务器设置 query_condition_cache_size（默认值：100 MB）配置查询条件缓存的最大大小。 100 MB 的缓存大小对应于 100 * 1024 * 1024 * 8 = 838,860,800 个条目。由于每个条目代表一个标记（默认情况下为 8192 行），因此该缓存可以覆盖单个列的 6,871,947,673,600（6.8 万亿）行。在实践中，筛选条件是在多个列上评估的，因此需要将该数字除以筛选列的数量。

配置设置和用法

设置 use_query_condition_cache 控制特定查询或当前会话的所有查询是否应利用查询条件缓存。

例如，第一次执行查询

SELECT col1, col2
FROM table
WHERE col1 = 'x'
SETTINGS use_query_condition_cache = true;

将存储不满足谓词的表的范围。随后执行相同的查询，并且参数 use_query_condition_cache = true，将利用查询条件缓存来扫描更少的数据。

管理

查询条件缓存不会在 ClickHouse 重启之间保留。

要清除查询条件缓存，请运行 SYSTEM CLEAR QUERY CONDITION CACHE。

缓存的内容在系统表 system.query_condition_cache 中显示。要以 MB 为单位计算查询条件缓存的当前大小，请运行 SELECT formatReadableSize(sum(entry_size)) FROM system.query_condition_cache。如果您想调查单个筛选条件，可以检查 system.query_condition_cache 中的字段 condition。请注意，此字段仅在调试版本中可用。

数据库启动以来查询条件缓存命中和未命中的次数显示为系统表 system.events 中的事件“QueryConditionCacheHits”和“QueryConditionCacheMisses”。仅当运行设置 use_query_condition_cache = true 的 SELECT 查询时，这两个计数器才会更新，其他查询不会影响“QueryCacheMisses”。

内存消耗​

配置设置和用法​

管理​

相关内容​

内存消耗

配置设置和用法

管理

相关内容