之前有一篇文章总结过和clickhouse监控相关的系统表，见前文：clickhouse之监控系列1-系统表。后来发现在使用clickhouse的过程中，还有很多的系统表对于排查问题和了解当前数据库的运行状态十分有帮助，因此结合官方文档和自己的使用经验，整理如下：
1.资源类2. 任务类
2.1. system.replication_queue2.2 system.distribution_queue2.3 system.distributed_ddl_queue 3. 日志类
3.1 system.query_log3.2 system.errors3.3 system.session_log 4. 辅助类
4.1 system.numbers4.2 system.zookeeper
1.资源类| 表名 | 用途 |
|---|---|
| system.clusters | 包含配置文件中可用的集群信息以及该集群中的节点信息 |
| system.databases | 包含了当前用户可用的数据库的信息，比如数据存储路径等 |
| system.tables | 包含每张表的元数据信息，包括建表语句，主键。分区键、条数、大小等信息 |
| system.disks | 包含配置文件中定义的磁盘信息，空间总大小，可用空间大小等 |
| system.dictionaries | 包含所有定义过的字典信息 |
| system.data_skipping_indices | 包含了所有定义过的跳数索引的信息 |
| system.replicas | 包含了所有副本相关的信息 |
| system.parts | 包含了所有数据分片的信息，这里面最小粒度的统计表，经常用于数据统计 |
如果你使用的是ReplicatedMergeTree引擎，那么这张表你大概率会用到，它的数据来源于zookeeper上每张表下面的replication queues节点。根据clickhouse副本同步的原理，当你有数据分片需要同步到副本时，不是直接和副本通信，而是把要同步的信息作为一个任务提交到replication queues这个队列中，每个副本监听这个队列，在后台完成数据同步的任务。通过这张表，你可以看到正在同步的分片信息，包括分片所属的表名、副本名称、任务类型（获取数据、合并数据等）、新的part名称、merge的part列表等。
比如一个data part文件不小心被删除了，如果触发检测以后，ch就会从其他副本上把丢失的文件同步过来，这时候你就可以在该表中看到一条记录了。 可见前文：不小心把clickhouse的数据文件删了，还可以恢复吗
与system.replication_queue相对应，system.distribution_queue针对的是DistributedXX系列的表引擎，当我们往一张分布式表里插入数据时，便会往该队列里插入一条数据，用于记录需要同步到其他各个分片的文件信息。不过除非是小数据量的数据写入，一般持续的大批量的数据写入我们通常不采用直接写分布式表的方法，而是通过前置负载均衡措施，将数据分散直接写入各个分片上的本地表。
2.3 system.distributed_ddl_queue记录的是定义在集群上的所有DDL操作，比如建表、删表等操作。
3. 日志类3.1 system.query_log日志类的表格通常用于监控服务状态，我在前文的监控系列中已经介绍过三张最常用的表。
这应该是比较常用的一张表。里面记录了所有执行过的查询操作，包括查询的起始时间、耗时等以及查询失败的信息。
注意：这里面不包括插入请求。
记录的是每种系统错误出现的次数，一般在排障的时候会用到。
3.3 system.session_log记录了系统的登入、登出日志。
4. 辅助类 4.1 system.numbers这张表记录着0开始的自然数，每一行代表一个自然数，经常用来做测试。
如果你懒得登录zookeeper客户端来查看zookeeper上存储的内容的话，那么你可以直接借助这张表来查询，注意：查这张表时必须带着where path='xxx'的查询条件。
我一般用到的就这些了，如果有想了解每张表每个字段内容的同学可以到官网进行查阅~~。
