是否曾想过如何在 ClickHouse 中调试问题？需要特定的统计信息，或者您是否对用户正在执行的查询以及失败的查询感到好奇？或者您可能需要识别当前应用的设置。系统表就能满足您的需求！在本文中，我们将探讨 ClickHouse 中的系统表，并展示我们在 ClickHouse 支持中如何使用它们来调试问题，并通过实际示例了解您的集群使用情况。
系统表简介
ClickHouse 中的系统表是虚拟表，提供有关服务器状态、进程和操作环境的信息。这些系统表位于 system 数据库中，仅供用户读取。它们不能被删除或更改，但它们的分区可以被分离，旧记录可以使用 TTL 删除。系统表为深入了解 ClickHouse 的内部操作提供了极佳的视角，并且在优化查询、监控系统性能或排除系统崩溃故障时，可以作为有价值的信息来源。
一般来说，ClickHouse 中有几种类型的系统表，其中一些有用的表包含与您的 database、tables、columns 和 parts 相关的系统信息。还有一些表显示实时信息，例如 metrics 和 events，提供当前系统事件的快照视图。用户还可以在系统日志表中找到历史记录，例如 metric_log、query_log、part_log 等。在集群中，distribution_queue 和 replication_queue 可用于排除分布式设置的故障。与 settings、users 和 roles 相关的表还提供有关当前配置和用户权限的信息。
大多数系统表将其数据存储在内存中，但系统日志表（如 metric_log、query_log 和 part_log）默认使用 MergeTree 表引擎并将数据存储在文件系统中。这种持久存储确保在服务器重启后日志仍然可用于分析。
系统表在哪里？
可以通过 SHOW TABLES FROM system 语句访问系统表的完整列表。您还可以在我们的 文档 中找到大多数系统表的扩展描述。
SHOW TABLES FROM system ┌─name───────────────────────────┐ │ aggregate_function_combinators │ │ asynchronous_inserts │ │ asynchronous_metric_log │ │ asynchronous_metric_log_0 │ │ asynchronous_metrics │ │ backups │ │ build_options │ │ certificates │ │ clusters │ │ collations │ │ columns │ │ contributors │ │ current_roles │ │ data_skipping_indices │ │ data_type_families │ │ databases │
与任何其他表一样，我们可以运行典型的 select 查询，例如 SELECT * FROM system.databases，以检索指定表中的行。
SELECT * FROM system.databases LIMIT 2 FORMAT Vertical Row 1: ────── name: INFORMATION_SCHEMA engine: Memory data_path: /var/lib/clickhouse/ metadata_path: uuid: 00000000-0000-0000-0000-000000000000 comment: Row 2: ────── name: blogs engine: Replicated data_path: /var/lib/clickhouse/store/ metadata_path: /var/lib/clickhouse/store/912/9125f586-0e3f-48f6-85b0-ccc76380e1a2/ uuid: 9125f586-0e3f-48f6-85b0-ccc76380e1a2 comment: 2 rows in set. Elapsed: 0.001 sec.
对这些表进行聚合使我们能够编写更复杂的查询，并更深入地了解 ClickHouse 的状态。
SELECT engine, count() AS count FROM system.databases GROUP BY engine ┌─engine─────┬─count─┐ │ Memory │ 2 │ │ Atomic │ 1 │ │ Replicated │ 8 │ └────────────┴───────┘ 3 rows in set. Elapsed: 0.015 sec.
那么，我们可以从系统表中收集到哪些有价值的见解呢？
查询系统表的热门技巧
在本节中，我们将重点介绍一些有用的系统表，这些表可以帮助回答我们在使用 ClickHouse 时可能遇到的常见问题。
哪些设置已从默认值更改？
首先，我们开始查看已从默认值更改的设置列表（使用 system.settings）。在故障排除期间，这是分析更改的设置是否可能影响系统行为的绝佳第一步。
SELECT * FROM system.settings WHERE changed LIMIT 2 FORMAT Vertical Row 1: ────── name: max_insert_threads value: 4 changed: 1 description: The maximum number of threads to execute the INSERT SELECT query. Values 0 or 1 means that INSERT SELECT is not run in parallel. Higher values will lead to higher memory usage. Parallel INSERT SELECT has effect only if the SELECT part is run on parallel, see 'max_threads' setting. min: ᴺᵁᴸᴸ max: ᴺᵁᴸᴸ readonly: 0 type: UInt64 Row 2: ────── name: max_threads value: 60 changed: 1 description: The maximum number of threads to execute the request. By default, it is determined automatically. min: ᴺᵁᴸᴸ max: ᴺᵁᴸᴸ readonly: 0 type: MaxThreads 2 rows in set. Elapsed: 0.003 sec.
哪些是长时间运行的查询？哪些查询占用了最多的内存？
接下来，我们深入研究查询日志表 (system.query_log)，该表包含有关已执行查询的大量信息。它通常是识别长时间运行、内存密集型或失败查询的首选表。
使用下面的查询，我们可以生成执行时间最长的查询的概览。我们还选择了其他列，例如 memory_usage、userCPU 和 systemCPU，以便我们了解资源利用率。最重要的是，函数 normalizedQueryHash 将相似的查询哈希为相同的 64 位哈希值，使我们能够进一步聚合该值并监控相似查询的性能。
下面的相同查询也可以用于查找占用最多内存的查询。只需将排序键替换为 memory_usage 即可。请注意，每个成功的查询都会在 query_log 中记录两个条目。第一个查询的类型为 QueryStart，最后一个查询的类型为 QueryFinish。我们特别关注 QueryFinish 行，因为这些行将记录执行查询的时间和使用的资源。
SELECT type, event_time, query_duration_ms, initial_query_id, formatReadableSize(memory_usage) AS memory, `ProfileEvents.Values`[indexOf(`ProfileEvents.Names`, 'UserTimeMicroseconds')] AS userCPU, `ProfileEvents.Values`[indexOf(`ProfileEvents.Names`, 'SystemTimeMicroseconds')] AS systemCPU, normalizedQueryHash(query) AS normalized_query_hash, substring(normalizeQuery(query) AS query, 1, 100) FROM system.query_log ORDER BY query_duration_ms DESC LIMIT 2 FORMAT Vertical Row 1: ────── type: QueryFinish event_time: 2022-11-26 11:50:14 query_duration_ms: 600802 initial_query_id: feb4c490-b420-47d3-a7ee-8c87fc68bf45 memory: 631.64 MiB userCPU: 27404274713 systemCPU: 234596117 normalized_query_hash: 17959601262672325984 substring(normalizeQuery(query), 1, 100): SELECT count() AS c FROM wikistat GROUP BY time Row 2: ────── type: QueryFinish event_time: 2022-11-26 15:05:39 query_duration_ms: 545026 initial_query_id: 8196b460-7a6a-434e-9324-14fc765a9a76 memory: 690.21 MiB userCPU: 28103266351 systemCPU: 324925435 normalized_query_hash: 8457232685578498203 substring(normalizeQuery(query), 1, 100): SELECT `time`, count() AS `c` FROM `default`.`wikistat` GROUP BY `time` ORDER BY `time` ASC WITH FIL 2 rows in set. Elapsed: 0.244 sec. Processed 8.49 million rows, 4.70 GB (34.75 million rows/s., 19.22 GB/s.)
哪些查询失败了？
并非所有查询都完美编写，有些查询执行失败。ExceptionBeforeStart 和 ExceptionWhileProcessing 是执行查询时可能发生的两种异常事件类型。以下是一个查询，用于筛选这些异常并显示异常消息和堆栈跟踪，以及诸如 used_aggregate_functions 等列。此信息对于故障排除很有帮助。
SELECT type, query_start_time, query_duration_ms, query_id, query_kind, is_initial_query, normalizeQuery(query) AS normalized_query, concat(toString(read_rows), ' rows / ', formatReadableSize(read_bytes)) AS read, concat(toString(written_rows), ' rows / ', formatReadableSize(written_bytes)) AS written, concat(toString(result_rows), ' rows / ', formatReadableSize(result_bytes)) AS result, formatReadableSize(memory_usage) AS `memory usage`, exception, concat('\n', stack_trace) AS stack_trace, user, initial_user, multiIf(empty(client_name), http_user_agent, concat(client_name, ' ', toString(client_version_major), '.', toString(client_version_minor), '.', toString(client_version_patch))) AS client, client_hostname, databases, tables, columns, used_aggregate_functions, used_aggregate_function_combinators, used_database_engines, used_data_type_families, used_dictionaries, used_formats, used_functions, used_storages, used_table_functions, thread_ids, ProfileEvents, Settings FROM system.query_log WHERE type IN ['3', '4'] ORDER BY query_start_time DESC LIMIT 1 FORMAT Vertical Row 1: ────── type: ExceptionBeforeStart query_start_time: 2022-12-12 09:50:52 query_duration_ms: 0 query_id: eec8ab27-51a6-4cde-ae3d-c306c13de5eb query_kind: Select is_initial_query: 1 normalized_query: select x from taxi_zone_dictionary read: 0 rows / 0.00 B written: 0 rows / 0.00 B result: 0 rows / 0.00 B memory usage: 0.00 B exception: Code: 47. DB::Exception: Missing columns: 'x' while processing query: 'SELECT x FROM taxi_zone_dictionary', required columns: 'x'. (UNKNOWN_IDENTIFIER) (version 22.11.1.1360 (official build)) stack_trace: 0. DB::Exception::Exception(std::__1::basic_string, std::__1::allocator> const&, int, bool) @ 0xbd145e8 in /usr/bin/clickhouse 1. DB::TreeRewriterResult::collectUsedColumns(std::__1::shared_ptr const&, bool, bool) @ 0x10ad376c in /usr/bin/clickhouse 2. DB::TreeRewriter::analyzeSelect(std::__1::shared_ptr&, DB::TreeRewriterResult&&, DB::SelectQueryOptions const&, std::__1::vector> const&, std::__1::vector, std::__1::allocator>, std::__1::allocator, std::__1::allocator>>> const&, std::__1::shared_ptr) const @ 0x10ad7fac in /usr/bin/clickhouse 3. ? @ 0x1083b550 in /usr/bin/clickhouse 4. DB::InterpreterSelectQuery::InterpreterSelectQuery(std::__1::shared_ptr const&, std::__1::shared_ptr const&, std::__1::optional, std::__1::shared_ptr const&, DB::SelectQueryOptions const&, std::__1::vector, std::__1::allocator>, std::__1::allocator, std::__1::allocator>>> const&, std::__1::shared_ptr const&, std::__1::shared_ptr) @ 0x10838454 in /usr/bin/clickhouse 5. DB::InterpreterSelectWithUnionQuery:: buildCurrentChildInterpreter(std::__1::shared_ptr const&, std::__1::vector, std::__1::allocator>, std::__1::allocator, std::__1::allocator>>> const&) @ 0x108d1dcc in /usr/bin/clickhouse 6. DB::InterpreterSelectWithUnionQuery:: InterpreterSelectWithUnionQuery(std::__1::shared_ptr const&, std::__1::shared_ptr, DB::SelectQueryOptions const&, std::__1::vector, std::__1::allocator>, std::__1::allocator, std::__1::allocator>>> const&) @ 0x108cfb68 in /usr/bin/clickhouse 7. DB::InterpreterFactory::get(std::__1::shared_ptr&, std::__1::shared_ptr, DB::SelectQueryOptions const&) @ 0x107fe174 in /usr/bin/clickhouse 8. ? @ 0x10b70ab8 in /usr/bin/clickhouse 9. DB::executeQuery(std::__1::basic_string, std::__1::allocator> const&, std::__1::shared_ptr, bool, DB::QueryProcessingStage::Enum) @ 0x10b6e684 in /usr/bin/clickhouse 10. DB::TCPHandler::runImpl() @ 0x11637db0 in /usr/bin/clickhouse 11. DB::TCPHandler::run() @ 0x11648ec4 in /usr/bin/clickhouse 12. Poco::Net::TCPServerConnection::start() @ 0x1225a98c in /usr/bin/clickhouse 13. Poco::Net::TCPServerDispatcher::run() @ 0x1225c520 in /usr/bin/clickhouse 14. Poco::PooledThread::run() @ 0x12416c5c in /usr/bin/clickhouse 15. Poco::ThreadImpl::runnableEntry(void*) @ 0x12414524 in /usr/bin/clickhouse 16. start_thread @ 0x7624 in /usr/lib/aarch64-linux-gnu/libpthread-2.31.so 17. ? @ 0xd149c in /usr/lib/aarch64-linux-gnu/libc-2.31.so user: default initial_user: default client: ClickHouse 22.10.2 client_hostname: derek-clickhouse databases: [] tables: [] columns: [] used_aggregate_functions: [] used_aggregate_function_combinators: [] used_database_engines: [] used_data_type_families: [] used_dictionaries: [] used_formats: [] used_functions: [] used_storages: [] used_table_functions: [] thread_ids: [] ProfileEvents: {} Settings: {} 1 row in set. Elapsed: 0.019 sec.
常见的错误是什么？
接下来，我们探索 system.errors 表。该表包含错误代码以及每个错误被触发的次数。此外，我们可以看到错误上次发生的时间以及确切的错误消息。last_error_trace 列还包含用于调试的 堆栈跟踪，有助于内省服务器状态。
SELECT name, code, value, last_error_time, last_error_message, last_error_trace AS remote FROM system.errors LIMIT 1 FORMAT Vertical Row 1: ────── name: CANNOT_READ_FROM_ISTREAM code: 23 value: 1016 last_error_time: 2022-12-21 11:43:06 last_error_message: Cannot read from istream at offset 0 remote: [228387450,270427334,306047695,310642709,310640492, 310861745,310860816,310860718,315390197,129746296,129744797,229143926, 229154103,229129110,229149953,140698656110089,140698655211827] 1 row in set. Elapsed: 0.002 sec.
插入行时是否正在创建 part？
MergeTree 系列中的引擎旨在将数据快速写入表中的小 part，然后在后台将这些 part 合并为更大的 part。为了确认插入的行已成功写入磁盘作为 part，我们可以查看 system.part_log 并检查是否及时创建了新的 part。
SELECT event_time, event_time_microseconds, rows FROM system.part_log WHERE (database = 'default') AND (table = 'github_events') AND (event_type IN ['NewPart']) ORDER BY event_time ASC LIMIT 10 ┌──────────event_time─┬────event_time_microseconds─┬───rows─┐ │ 2022-12-12 10:54:42 │ 2022-12-12 10:54:42.373583 │ 573440 │ │ 2022-12-12 10:54:45 │ 2022-12-12 10:54:45.116786 │ 507904 │ │ 2022-12-12 10:54:47 │ 2022-12-12 10:54:47.374676 │ 312032 │ │ 2022-12-12 10:54:49 │ 2022-12-12 10:54:49.598769 │ 434176 │ │ 2022-12-12 10:54:51 │ 2022-12-12 10:54:51.824833 │ 368638 │ │ 2022-12-12 10:54:53 │ 2022-12-12 10:54:53.964555 │ 548864 │ │ 2022-12-12 10:54:56 │ 2022-12-12 10:54:56.286868 │ 524288 │ │ 2022-12-12 10:54:58 │ 2022-12-12 10:54:58.892573 │ 253948 │ │ 2022-12-12 10:55:01 │ 2022-12-12 10:55:01.404872 │ 450560 │ │ 2022-12-12 10:55:03 │ 2022-12-12 10:55:03.630993 │ 328850 │ └─────────────────────┴────────────────────────────┴────────┘ 10 rows in set. Elapsed: 0.012 sec. Processed 4.96 thousand rows, 292.42 KB (404.05 thousand rows/s., 23.80 MB/s.)
正在进行的合并的状态是什么？
由于新创建的 part 在后台不断合并，我们可以使用 system.merges 表来监视长时间运行的合并。完成时间过长的合并可能意味着某些系统资源（例如 CPU、磁盘 IO）已达到饱和点。
SELECT hostName(), database, table, round(elapsed, 0) AS time, round(progress, 4) AS percent, formatReadableTimeDelta((elapsed / progress) - elapsed) AS ETA, num_parts, formatReadableSize(memory_usage) AS memory_usage, result_part_name FROM system.merges ORDER BY (elapsed / percent) - elapsed ASC FORMAT Vertical Row 1: ────── hostName(): c-mint-mb-85-server-0 database: default table: minicrawl time: 831 percent: 0.6428 ETA: 7 minutes and 41 seconds num_parts: 6 memory_usage: 1.50 GiB result_part_name: all_839_1124_4 2 rows in set. Elapsed: 0.360 sec.
是否有带有错误的 part？
为了识别 part 合并期间的错误，我们可以再次检查 system.part_log 表，以揭示特定事件类型的 data part 错误发生的次数。错误代码被 解析 为各自的错误名称，并充当我们调整查询或提供额外资源的反馈机制。错误代码和名称的完整列表可以在 此处 找到。
SELECT event_date, event_type, table, error AS error_code, errorCodeToName(error) AS error_code_name, count() as c FROM system.part_log WHERE (error_code != 0) AND (event_date > (now() - toIntervalMonth(1))) GROUP BY event_date, event_type, error, table ORDER BY event_date DESC, event_type ASC, table ASC, error ASC ┌─event_date─┬─event_type───┬─table──┬─error_code─┬─error_code_name─────────┬────c────┐ │ 2022-12-12 │ MergeParts │ events │ 241 │ MEMORY_LIMIT_EXCEEDED │ 77 │ │ 2022-12-06 │ MergeParts │ events │ 241 │ MEMORY_LIMIT_EXCEEDED │ 16 │ │ 2022-11-28 │ NewPart │ x │ 389 │ INSERT_WAS_DEDUPLICATED │ 38 │ │ 2022-11-28 │ NewPart │ x │ 394 │ QUERY_WAS_CANCELLED │ 1 │ │ 2022-11-28 │ MergeParts │ events │ 236 │ ABORTED │ 25 │ │ 2022-11-28 │ MutatePart │ events │ 236 │ ABORTED │ 68 │ │ 2022-11-27 │ MergeParts │ events │ 236 │ ABORTED │ 1 │ │ 2022-11-27 │ MutatePart │ events │ 236 │ ABORTED │ 9 │ │ 2022-11-26 │ MergeParts │ events │ 236 │ ABORTED │ 26 │ │ 2022-11-26 │ MutatePart │ events │ 236 │ ABORTED │ 282 │ │ 2022-11-25 │ NewPart │ x │ 394 │ QUERY_WAS_CANCELLED │ 1 │ │ 2022-11-25 │ MutatePart │ events │ 236 │ ABORTED │ 14 │ │ 2022-11-24 │ MergeParts │ events │ 236 │ ABORTED │ 55 │ │ 2022-11-24 │ MergeParts │ events │ 241 │ MEMORY_LIMIT_EXCEEDED │ 158 │ │ 2022-11-24 │ DownloadPart │ events │ 1000 │ POCO_EXCEPTION │ 4 │ │ 2022-11-24 │ MutatePart │ events │ 236 │ ABORTED │ 119 │ │ 2022-11-23 │ MergeParts │ events │ 241 │ MEMORY_LIMIT_EXCEEDED │ 174 │ │ 2022-11-23 │ DownloadPart │ events │ 1000 │ POCO_EXCEPTION │ 12 │ │ 2022-11-22 │ MergeParts │ events │ 241 │ MEMORY_LIMIT_EXCEEDED │ 70 │ └────────────┴──────────────┴────────┴────────────┴─────────────────────────┴─────────┘ 19 rows in set. Elapsed: 0.008 sec. Processed 73.25 thousand rows, 1.61 MB (8.99 million rows/s., 198.00 MB/s.)
是否有卡住的长时间运行的 mutation？
ALTER 查询，也称为 mutation，通过重写整个 data part 来操作表数据。因此，这可能是一项资源密集型操作，如果需要修改大量 part，并且可能会影响正常的合并操作，则可能需要很长时间才能完成。下面的查询列出了正在进行的 mutation，并显示了失败原因（如果有）。
SELECT database, table, mutation_id, command, create_time, parts_to_do_names, parts_to_do, is_done, latest_failed_part, latest_fail_time, latest_fail_reason FROM system.mutations WHERE NOT is_done ORDER BY create_time DESC Row 1: ────── database: default table: events_wide_new mutation_id: 0000000001 command: DROP COLUMN col798 create_time: 2022-12-12 16:19:53 parts_to_do_names: ['20221212_6_41_2_86','20221212_42_71_2_86','20221212_72_99_2_86','20221212_106_139_2'] parts_to_do: 4 is_done: 0 latest_failed_part: latest_fail_time: 1970-01-01 00:00:00 latest_fail_reason: 1 row in set. Elapsed: 0.002 sec.
表正在使用多少磁盘空间？
ClickHouse 使用 LZ4 压缩编解码器 默认情况下（在 ClickHouse Cloud 中，我们实际上使用 ZSTD - 有关更多详细信息，请参阅 此处 ），数据压缩效果非常好。但是，有时我们可能会好奇想知道每个表正在使用多少磁盘空间。下面的查询使用 system.parts 表向我们显示每个非系统表占用的磁盘空间总量 (total_bytes_on_disk)，以及压缩 data part 的总大小 (data_compressed_bytes) 以及这些 data part 解压缩时的大小 (data_uncompressed_bytes)。在下面的示例中，我们可以从 compression_ratio 列中观察到，压缩数据仅占用不到 40% 的磁盘空间！对于那些有兴趣进一步最大限度地减少存储空间的人，请查看我们关于 使用架构和编解码器优化 ClickHouse 的博客文章。
SELECT hostName(), database, table, sum(rows) AS rows, formatReadableSize(sum(bytes_on_disk)) AS total_bytes_on_disk, formatReadableSize(sum(data_compressed_bytes)) AS total_data_compressed_bytes, formatReadableSize(sum(data_uncompressed_bytes)) AS total_data_uncompressed_bytes, round(sum(data_compressed_bytes) / sum(data_uncompressed_bytes), 3) AS compression_ratio FROM system.parts WHERE database != 'system' GROUP BY hostName(), database, table ORDER BY sum(bytes_on_disk) DESC FORMAT Vertical Row 1: ────── hostName(): c-mint-mb-85-server-0 database: default table: reddit rows: 9946243959 total_bytes_on_disk: 718.47 GiB total_data_compressed_bytes: 717.39 GiB total_data_uncompressed_bytes: 2.22 TiB compression_ratio: 0.315 Row 2: ────── hostName(): c-mint-mb-85-server-0 database: default table: wikistat rows: 417565645200 total_bytes_on_disk: 579.44 GiB total_data_compressed_bytes: 554.31 GiB total_data_uncompressed_bytes: 14.12 TiB compression_ratio: 0.038 2 rows in set. Elapsed: 0.004 sec.
正在移动的 part 的状态是什么？
除了后台合并 part 外，part 和分区还可以在磁盘和卷之间移动。例如，通常的做法是首先将最近写入的 part 存储在热卷 (SSD) 上，然后在它们超过一定期限后自动将它们移动到冷卷 (HDD)。此操作可以使用 TTL 子句 完成，也可以使用 ALTER 语句 触发。当 part 正在移动时，我们可以使用 最近引入的 system.moves 表来监视经过的时间和目标磁盘。下面的查询显示，part (all_1_22_2) 正在移动到 s3 磁盘的过程中。
ALTER TABLE ontime MOVE PART 'all_1_22_2' TO VOLUME 'external';
SELECT * FROM system.moves FORMAT Vertical Row 1: ────── database: default table: ontime elapsed: 8.900590354 target_disk_name: s3 target_disk_path: /var/lib/clickhouse/disks/s3_disk/ part_name: all_1_22_2 part_size: 1643771811 thread_id: 10071 1 row in set. Elapsed: 0.160 sec.
从集群中所有节点查询系统表
在集群中查询系统表时，请注意查询仅在发出查询的本地节点上执行。要从具有分片和副本的集群中的所有节点检索行，我们需要使用 clusterAllReplicas 表函数。下面的查询被发送到具有两个分片的集群，每个分片有两个副本。根据 hostName，我们可以看到结果行是从所有四个节点收集的。
SELECT hostName(), is_initial_query, query_id, initial_query_id, query FROM clusterAllReplicas('default', system.processes) FORMAT Vertical Row 1: ────── hostName(): c-mint-mb-85-server-0 is_initial_query: 1 query_id: c8f1cfb2-7eed-4ecd-a303-cc20ef5d9d0f initial_query_id: c8f1cfb2-7eed-4ecd-a303-cc20ef5d9d0f query: SELECT hostName(), is_initial_query, query_id, initial_query_id, query FROM clusterAllReplicas('default', system.processes) FORMAT Vertical Row 2: ────── hostName(): c-mint-mb-85-server-1 is_initial_query: 0 query_id: e487bae2-0886-46ef-8510-87c218f45332 initial_query_id: c8f1cfb2-7eed-4ecd-a303-cc20ef5d9d0f query: SELECT hostName(), `is_initial_query`, `query_id`, `initial_query_id`, `query` FROM `system`.`processes` Row 3: ────── hostName(): c-mint-mb-85-server-2 is_initial_query: 0 query_id: 271abbde-64b9-46ea-9391-9f402cc013ef initial_query_id: c8f1cfb2-7eed-4ecd-a303-cc20ef5d9d0f query: SELECT hostName(), `is_initial_query`, `query_id`, `initial_query_id`, `query` FROM `system`.`processes` 3 rows in set. Elapsed: 0.006 sec.
结论
在本文中，我们介绍了如何使用系统表来查询 ClickHouse 的当前和历史状态。我们提供了使用系统表回答使用 ClickHouse 时一些常见问题的示例。在未来的文章中，我们将更详细地探讨这些表，以及如何使用它们来监控 ClickHouse 中 INSERT 和 SELECT 查询的常见挑战。
