Перейти к основному содержанию

Ответ

Таблица query_log в базе данных system хранит информацию обо всех ваших запросах, включая:
  • сколько памяти потребил запрос, и
  • сколько процессорного времени потребовалось
Следующий запрос возвращает 10 запросов, использовавших больше всего памяти:
Ответ выглядит следующим образом:
initial_query_id — это идентификатор исходного запроса при выполнении распределённого запроса, запущенного с узла, принимающего запрос. query_id содержит идентификатор дочернего запроса, который выполняется на другом узле. Подробнее см. в этой статье.
Идентификатор запроса можно использовать, чтобы получить о нём более подробные сведения. Давайте рассмотрим самый долгий запрос из приведённых выше (первый):
Как оказалось, это тот самый запрос, который мы использовали для вставки нескольких миллиардов строк в таблицу youtube (см. набор данных о дизлайках YouTube):

initial_query_id VS query_id

Обратите внимание: в кластерной среде ClickHouse (например, в ClickHouse Cloud) initial_query_id — это идентификатор исходного запроса для выполнения распределённого запроса, запущенного с узла, принимающего запрос; а поле query_id содержит идентификатор дочернего запроса, выполняемого на другом узле.
Распределённое выполнение — не единственная причина различий в значениях query_idОдин запрос также может порождать внутренние подзапросы, которые записываются со своими собственными query_id и is_initial_query = 0 — чаще всего это внутренние запросы, которые ClickHouse выполняет для обработки представлений. Эти внутренние идентификаторы назначаются ClickHouse и могут не совпадать по формату с идентификатором, который передаётся вашему клиенту; на этапах, связанных с представлениями, вы можете увидеть значения query_id, содержащие метку вроде queryView.... Если вам нужен запрос именно в том виде, в котором вы его отправили, фильтруйте по is_initial_query = 1 (или query_id = initial_query_id). Это серверное поведение query_log, и оно одинаково для любого клиента, включая Cloud SQL Console.
Если добавить query_id в приведённый выше запрос, поиск будет ограничен значениями initial_query_id = a7262fa2-bd8b-4b51-a359-621ccf282417 и hostname():
в результате получим:
Обратите внимание, что у нас есть несколько результатов с нескольких хостов (разных узлов кластера). Чтобы сузить выборку и получить только дочерние запросы, мы также можем добавить условие query_id != initial_query_id в предложение WHERE:
возвращает все дочерние запросы, выполненные на удалённых узлах (то есть узлах, удалённых относительно узла, на котором запрос был впервые запущен):
И наоборот, query_id = initial_query_id вернёт только запросы, выполненные на локальном узле, на котором распределённый запрос был изначально запущен:
получаем:
Для других системных таблиц более подробную информацию о значении каждого поля можно найти в нашей документации.
Последнее изменение 1 июля 2026 г.