system.query_log — 쿼리가 끝난 뒤 무슨 일이 있었는지 되짚어보기
ClickHouse CollapsingMergeTree/VersionedCollapsingMergeTree 및 system.query_log 공식 문서 종합 (웹 리서치, 2026) — ClickHouse 공식 문서(engines/table-engines/mergetree-family/collapsingmergetree, versionedcollapsingmergetree, operations/system-tables/query_log) ClickHouse 공식문서 system.query_log
이 모듈을 다 읽으면
- system.query_log가 EXPLAIN과 어떻게 역할이 다른지(사전 계획 확인 vs 사후 실측 이력) 설명할 수 있다
- 성공한 쿼리마다 QueryStart/QueryFinish 두 행이 남는 이유와 query_duration_ms의 의미를 설명할 수 있다
clickhouse-learn-10에서 다룬 EXPLAIN(실행 전에 계획을 미리 보는 도구)과 대비해, system.query_log가 이미 실행된 쿼리들의 실측 이력을 사후에 되짚어보는 시스템 테이블이라는 것을 정리한다.
EXPLAIN과의 역할 차이 — 사전 계획 vs 사후 이력
clickhouse-learn-10의 EXPLAIN이 '이 쿼리를 실행하면 어떤 계획으로 처리될 것인가'를 실행 전에 미리 보여주는 도구라면, system.query_log는 정반대로 '실제로 실행된 쿼리들이 각각 얼마나 걸렸고 어떤 상태로 끝났는지'를 사후에 기록해두는 시스템 테이블이다. 즉 EXPLAIN은 진단하려는 쿼리 하나를 대상으로 하는 사전 도구이고, query_log는 클러스터에서 실행된 모든 쿼리의 이력을 모아두는 사후 관측 도구라는 게 근본적인 역할 차이다.
핵심 포인트
- EXPLAIN(module10): 실행 전 계획을 미리 보는 사전 진단 도구
- system.query_log: 이미 실행된 모든 쿼리의 실측 이력을 모아두는 사후 관측용 시스템 테이블
성공한 쿼리마다 두 행(QueryStart/QueryFinish)이 남는다
query_log의 type 컬럼은 쿼리 실행 중 발생한 이벤트 종류를 나타내는데, QueryStart(쿼리 실행 성공적으로 시작)/QueryFinish(성공적으로 종료)/ExceptionBeforeStart(시작 전 예외)/ExceptionWhileProcessing(처리 중 예외) 네 값을 갖는다. 쿼리 실행이 성공하면 QueryStart와 QueryFinish 두 개의 행이 생긴다는 점이 특이한데, 이는 시작 시점과 종료 시점을 각각 별도 행으로 남겨 나중에 조인·분석하기 쉽게 하려는 설계다. query_duration_ms는 이 쿼리 실행에 걸린 시간(밀리초)을 나타내며, query_start_time_microseconds는 마이크로초 정밀도의 시작 시각을 담는다.
핵심 포인트
- type 컬럼: QueryStart/QueryFinish/ExceptionBeforeStart/ExceptionWhileProcessing 네 값 — 성공한 쿼리는 QueryStart+QueryFinish 두 행이 생김
- query_duration_ms(실행 소요시간, ms)와 query_start_time_microseconds(마이크로초 정밀도 시작시각)로 실제 걸린 시간을 정확히 추적