您是否曾经想过如何调试 ClickHouse 中的问题？需要特定统计数据，或者您对用户执行的查询以及失败的查询感到好奇吗？或者您可能需要识别当前应用的设置。系统表将是您的不二之选！在本文中，我们将探讨 ClickHouse 中的系统表，并展示我们如何在 ClickHouse 支持中使用它们来调试问题并通过实际示例了解您的集群使用情况。
系统表的介绍
ClickHouse 中的系统表是虚拟表，提供有关服务器状态、进程和操作环境的信息。这些系统表位于 system 数据库中，仅供用户读取。它们不能被删除或修改，但它们的 partition 可以被分离，旧记录可以使用 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.
插入行时是否正在创建部分？
MergeTree 系列中的引擎旨在将数据快速写入表中的小部分，然后再 将这些部分合并为较大的部分 在后台。为了确认插入的行是否已成功写入磁盘作为部分，我们可以查看 system.part_log 并检查是否及时创建了新部分。
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.)
正在进行的合并状态如何？
由于新创建的部分会不断在后台合并，我们可以使用 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.
是否有包含错误的部分？
为了识别零件合并过程中的错误，我们可以再次检查system.part_log 表格，以了解特定事件类型发生数据部分错误的次数。错误代码被解析为相应的错误名称，并作为反馈机制，帮助我们调整查询或提供额外资源。完整的错误代码和名称列表可以在这里找到。
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.)
是否存在卡住的长时间运行的变动操作？
ALTER 查询，也称为变动操作，通过重写整个数据部分来操作表格数据。因此，这可能是一个资源密集型操作，如果需要修改大量部分，则可能需要很长时间才能完成，并可能影响正常的合并操作。下面的查询列出了正在进行的变动操作，并显示了任何失败的原因。
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_compressed_bytes），以及这些数据部分解压缩后的尺寸（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.
正在移动的部分的状态如何？
除了后台的零件合并之外，零件和分区也可以在磁盘和卷之间移动。例如，常见的是先将最近写入的零件存储在热卷（SSD）上，然后在它们超过一定年龄时自动将其移动到冷卷（HDD）上。此操作可以使用TTL 子句 完成，也可以使用ALTER 语句 触发。当零件正在移动时，我们可以使用最近引入的 system.moves 表格来监控状态，观察经过的时间和目标磁盘。下面的查询显示一个零件（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 查询的常见挑战。
