system.processors_profile_log

在 ClickHouse Cloud 中查询

该系统表中的数据在 ClickHouse Cloud 的每个节点上本地保存。因此，要获得所有数据的完整视图，需要使用 clusterAllReplicas 函数。有关更多详细信息，请参见 here。

此表包含处理器级别的分析信息 (可以在 EXPLAIN PIPELINE 中找到)。

列：

• hostname (LowCardinality(String)) — 执行查询的服务器的主机名。
• event_date (Date) — 事件发生的日期。
• event_time (DateTime) — 事件发生的日期和时间。
• event_time_microseconds (DateTime64) — 事件发生的日期和时间，精确到微秒。
• id (UInt64) — 处理器的 ID。
• parent_ids (Array(UInt64)) — 父处理器的 IDs。
• plan_step (UInt64) — 创建此处理器的查询计划步骤的 ID。如果处理器不是从任何步骤添加的，则值为零。
• plan_group (UInt64) — 如果是由查询计划步骤创建的，则处理器的组。组是从同一查询计划步骤添加的处理器的逻辑分区。组仅用于美化 EXPLAIN PIPELINE 的结果。
• initial_query_id (String) — 初始查询的 ID（用于分布式查询执行）。
• query_id (String) — 查询的 ID。
• name (LowCardinality(String)) — 处理器的名称。
• elapsed_us (UInt64) — 此处理器执行的微秒数。
• input_wait_elapsed_us (UInt64) — 此处理器等待数据（来自其他处理器）的微秒数。
• output_wait_elapsed_us (UInt64) — 此处理器因输出端口已满而等待的微秒数。
• input_rows (UInt64) — 处理器消耗的行数。
• input_bytes (UInt64) — 处理器消耗的字节数。
• output_rows (UInt64) — 处理器生成的行数。
• output_bytes (UInt64) — 处理器生成的字节数。 示例

查询：

结果：

在这里你可以看到：

• ExpressionTransform 正在执行 sleep(1) 函数，因此它的 work 将占用 1e6，所以 elapsed_us > 1e6。
• SourceFromSingleChunk 需要等待，因为 ExpressionTransform 在执行 sleep(1) 时不接受任何数据，因此它将在 PortFull 状态下等待 1e6 us，因此 output_wait_elapsed_us > 1e6。
• LimitsCheckingTransform / NullSource / LazyOutputFormat 需要等待直到 ExpressionTransform 执行 sleep(1) 来处理结果，因此 input_wait_elapsed_us > 1e6。

另请参阅

• EXPLAIN PIPELINE