Почему мой первичный ключ не используется? Как это проверить?

Пользователи могут столкнуться с ситуацией, когда запрос выполняется медленнее, чем ожидалось, хотя кажется, что сортировка или фильтрация идут по первичному ключу. В этой статье мы покажем, как убедиться, что ключ действительно используется, а также разберём распространённые причины, по которым этого не происходит.

Рассмотрим простую таблицу:

CREATE TABLE logs
(
    `code` LowCardinality(String),
    `timestamp` DateTime64(3)
)
ENGINE = MergeTree
ORDER BY (code, toUnixTimestamp(timestamp))

Обратите внимание, что в качестве второго элемента наш ключ сортировки содержит toUnixTimestamp(timestamp).

Заполните эту таблицу 100 млн строками:

INSERT INTO logs SELECT
 ['200', '404', '502', '403'][toInt32(randBinomial(4, 0.1)) + 1] AS code,
    now() + toIntervalMinute(number) AS timestamp
FROM numbers(100000000)

0 rows in set. Elapsed: 15.845 sec. Processed 100.00 million rows, 800.00 MB (6.31 million rows/s., 50.49 MB/s.)

SELECT count()
FROM logs

┌

Если отфильтровать по коду, в выводе будет видно количество просканированных строк — 49.15 thousand. Обратите внимание, что это лишь часть от общего числа в 100 млн строк.

SELECT count() AS c
FROM logs
WHERE code = '200'

┌

Кроме того, использование индекса можно подтвердить с помощью конструкции EXPLAIN indexes=1:

EXPLAIN indexes = 1
SELECT count() AS c
FROM logs
WHERE code = '200'

┌

Обратите внимание, что количество просканированных гранул 8012 составляет лишь часть от общего числа 12209. Раздел, выделенный ниже, подтверждает, что используется первичный ключ.

PrimaryKey
  Keys: 
   code 

Гранулы — это единицы обработки данных в ClickHouse; каждая из них обычно содержит 8192 строк. Подробнее о гранулах и о том, как выполняется их фильтрация, см. в этом руководстве.

Предположим, что мы фильтруем по code и timestamp:

SELECT count()
FROM logs
WHERE (code = '200') AND (timestamp >= '2025-01-01 00:00:00') AND (timestamp <= '2026-01-01 00:00:00')

┌

В этом случае оба ключа сортировки используются для фильтрации строк, поэтому нужно прочитать лишь 87 гранул.

ClickHouse также может использовать ключи сортировки для эффективной сортировки. В частности,

Если включена настройка optimize_read_in_order (по умолчанию она включена), сервер ClickHouse использует индекс таблицы и читает данные в порядке, заданном ключом ORDER BY. Это позволяет не считывать все данные, если указан LIMIT. Поэтому запросы к большим объемам данных с небольшим LIMIT выполняются быстрее. Подробнее см. здесь и здесь.

Однако для этого используемые ключи должны быть согласованы.

Например, рассмотрим такой запрос:

SELECT *
FROM logs
WHERE (code = '200') AND (timestamp >= '2025-01-01 00:00:00') AND (timestamp <= '2026-01-01 00:00:00')
ORDER BY timestamp ASC
LIMIT 10

┌

Мы можем убедиться с помощью EXPLAIN pipeline, что эта оптимизация здесь не используется:

EXPLAIN PIPELINE
SELECT *
FROM logs
WHERE (code = '200') AND (timestamp >= '2025-01-01 00:00:00') AND (timestamp <= '2026-01-01 00:00:00')
ORDER BY timestamp ASC
LIMIT 10

┌

Строка MergeTreeSelect(pool: ReadPool, algorithm: Thread) здесь указывает не на использование оптимизации, а на обычное чтение. Это связано с тем, что в качестве ключа сортировки таблицы используется toUnixTimestamp(Timestamp), а НЕ timestamp. Устранение этого несоответствия решает проблему:

EXPLAIN PIPELINE
SELECT *
FROM logs
WHERE (code = '200') AND (timestamp >= '2025-01-01 00:00:00') AND (timestamp <= '2026-01-01 00:00:00')
ORDER BY toUnixTimestamp(timestamp) ASC
LIMIT 10

┌