Skip to main content
These settings are available in system.settings and are autogenerated from source.

​
query_cache_compress_entries

Compress entries in the query cache. Lessens the memory consumption of the query cache at the cost of slower inserts into / reads from it. Possible values:
  • 0 - Disabled
  • 1 - Enabled

​
query_cache_for_subqueries

If turned on, subquery results may be written to and read from the query cache. This enables propagation of use_query_cache into all subqueries. Possible values:
  • 0 - Disabled
  • 1 - Enabled

​
query_cache_max_entries

The maximum number of query results the current user may store in the query cache. 0 means unlimited. Possible values:
  • Positive integer >= 0.

​
query_cache_max_size_in_bytes

The maximum amount of memory (in bytes) the current user may allocate in the query cache. 0 means unlimited. Possible values:
  • Positive integer >= 0.

​
query_cache_min_query_duration

Minimum duration in milliseconds a query needs to run for its result to be stored in the query cache. Possible values:
  • Positive integer >= 0.

​
query_cache_min_query_runs

Minimum number of times a SELECT query must run before its result is stored in the query cache. Possible values:
  • Positive integer >= 0.

​
query_cache_nondeterministic_function_handling

Controls how the query cache handles SELECT queries with non-deterministic functions like rand() or now(). Possible values:
  • 'throw' - Throw an exception and don’t cache the query result.
  • 'save' - Cache the query result.
  • 'ignore' - Don’t cache the query result and don’t throw an exception.

​
query_cache_share_between_users

If turned on, the result of SELECT queries cached in the query cache can be read by other users. It is not recommended to enable this setting due to security reasons. Possible values:
  • 0 - Disabled
  • 1 - Enabled

​
query_cache_squash_partial_results

Squash partial result blocks to blocks of size max_block_size. Reduces performance of inserts into the query cache but improves the compressability of cache entries (see query_cache_compress-entries). Possible values:
  • 0 - Disabled
  • 1 - Enabled

​
query_cache_system_table_handling

Controls how the query cache handles SELECT queries against system tables, i.e. tables in databases system.* and information_schema.*. Possible values:
  • 'throw' - Throw an exception and don’t cache the query result.
  • 'save' - Cache the query result.
  • 'ignore' - Don’t cache the query result and don’t throw an exception.

​
query_cache_tag

A string which acts as a label for query cache entries. The same queries with different tags are considered different by the query cache. Possible values:
  • Any string

​
query_cache_ttl

After this time in seconds entries in the query cache become stale. Possible values:
  • Positive integer >= 0.

​
query_cache_use_only_when_data_was_not_changed

If turned on, a query cache entry is reused only if none of the tables referenced by the query were changed since the entry was cached. This makes the query cache consistent with respect to data changes, at the cost of recomputing the result whenever the underlying data changes (and of an extra check of the referenced tables on each lookup, which may be expensive for Merge, Distributed and URL tables). The referenced tables are examined once, at the start of the query, and the decision to reuse a cache entry is made against that snapshot; there is no second check just before the cached result is returned, so a write that commits after the query started can still be missed by that particular query, which observes the same data as if it had started slightly earlier. For URL and object-storage tables this check is based on the resource’s strong ETag and is best-effort: a result could in rare cases be reused if the content is rewritten back to a byte-identical state during the read. Merge and Distributed are likewise best-effort if the set of their underlying tables changes during a query, and row policies that exist only on remote shard servers of a Distributed table are not seen by the check. The check covers a table’s regular columns and data only; it does not cover query-visible virtual columns that expose placement or external metadata (for example _disk_name, _tags or _headers), so a query selecting such a column may reuse a cached result after only that column changed (e.g. a part moved between disks, or object tags or response headers changed). If consistency cannot be guaranteed, the query cache is not used for the query. This happens when the query references a table that cannot tell whether its data changed (e.g. a table function such as url), when the query calls a non-deterministic function (whose result can change while every referenced table is unchanged), when the query runs inside a transaction (the check sees the live table state, not the transaction’s snapshot), or when a referenced table has an active row policy for the current user (the policy can change what the user reads while every referenced table is unchanged). Possible values:
  • 0 - Disabled.
  • 1 - Enabled.
Last modified on August 9, 2026