本文围绕智能巡检项出现高风险的场景，提供了具体处理建议。您可结合实际触发高风险的巡检指标，查阅对应的应对方案。

节点宕机数

节点宕机时 ByteHouse 团队会高优先级介入处理，一般情况下会自动恢复。您也可以通过监控进一步确定宕机节点，如需查看监控信息，请通过集群管理 > 目标集群名 > 监控告警 > 操作系统负载 > 节点宕机数 查看。
如果节点宕机长时间未恢复，或需要立即处理，请联系 ByteHouse 售后支持团队。

分片宕机数

分片宕机时 ByteHouse 团队会高优先级介入处理，一般情况下会自动恢复。您也可以通过监控进一步确定宕机节点，可通过集群管理 > 目标集群名 > 监控告警 > 操作系统负载 > Shard 故障数 count 查看。
如果分片宕机长时间未恢复，或需要立即处理，请联系 ByteHouse 售后支持团队。

磁盘异常数

磁盘出现异常，通常是磁盘容量已满。您可通过监控查看磁盘是否已满，可通过集群管理 > 目标集群名 > 监控告警 > 操作系统负载 > 磁盘剩余容量 GiB 查看。
如果磁盘已满，可进行磁盘扩容，或删除部分历史数据。磁盘扩容操作可通过发起垂直变配，调整存储资源数值，请参见垂直变配。
如果扩容或删除历史数据后，仍无法恢复，请联系 ByteHouse 售后支持团队。

平均 CPU 使用率

CPU 使用率过高，通常是两类原因导致，一类是查询整体负载过高，另一类是个别大查询占用过多 CPU 资源。可通过以下步骤排查：

1. 通过监控指标，例如查询（Query）并发数、CPU 使用率，判断查询整体负载是否一直处于相对高位，或查询在某个时间窗口有明显的负载增加。如果是，建议对集群进行垂直扩容或水平扩容，具体操作请参考集群变配。
2. 如果已排除查询整体负载高的原因，可进一步对部分大查询进行识别和优化。
   您可以通过 SQL 诊断功能，查看消耗 CPU Top5 Query。也可以通过 SQL 诊断的 SQL 指纹分析能力，将同一类查询模式的 SQL 进行聚合，计算出它们的总条数、总 CPU 消耗等，从全局角度识别一类显著影响 CPU 性能的查询。SQL 诊断功能使用说明请参见SQL 诊断。
   识别出同一类的查询模式的 SQL 后，您可以通过 Query 洞察功能进一步获取查询计划等信息辅助排查。

IO 使用率

通过监控查看 ByteHouse 负载和查询负载中的指标，如查询（Query）并发数、后台合并（merge）任务数、并发数、数据导入任务等指标是否有激增，判断是否相关任务影响了 IO，可根据指标情况进一步优化查询。您可通过集群管理 > 目标集群名 > 监控告警 路径查看上述相关指标。
如果相关指标正常，但仍存在该异常，请联系 ByteHouse 售后支持团队处理。

平均内存使用率

可通过后台合并（merge）任务、运行中查询、查询缓存三方面排查内存使用率高的原因。详细说明和处理请见性能诊断之内存占用分析。

平均磁盘使用率

您可通过执行以下命令查找高磁盘占用表：

SELECT 
    table,
    sum(rows),
    formatReadableSize(sum(data_compressed_bytes)) AS size
FROM system.parts
GROUP BY table
ORDER BY sum(data_compressed_bytes) DESC
LIMIT 10;

当磁盘使用率过高时，建议通过以下方式优化：

• 方式一：磁盘扩容；
• 方式二：删除部分历史数据；
• 方式三：参考查看表占用磁盘空间大小，并结合以下命令定位优化目标。

若查询结果中表的占用大小与磁盘实际占用差异较大，可能是集群日志或元数据占用过多，建议联系 ByteHouse 售后支持团队进一步排查。

平均 iNode 占用比

文件数占用较高通常是因为小文件过多，ByteHouse 后台会进行自动合并小文件。如果长期存在 iNode 占用比高的情况，请联系 ByteHouse 售后支持团队。

系统盘使用率

出现该异常时，请联系 ByteHouse 售后支持团队。

集群 Part 数

您可执行以下命令，查询集群 part 数量分布，并定位存在 part 数异常的表及原因。使用时请使用实际的数据库、表信息替换示例中的占位符或示例内容。

1. 查看系统表 Part 数量分布：

   SELECT 
       database || '.' || table AS db_tbl,
       active,
       count(),
       sum(rows)
   FROM system.parts
   GROUP BY db_tbl,
            active
   ORDER BY count() DESC
   LIMIT 10;
   

2. 若发现 active parts 堆积，通过以下步骤定位问题表及原因：

   • 原因一：后台合并（merge）任务异常

     1. 对比写入与合并性能。

        SELECT 
            toHour(event_time) AS h, 
            countIf(event_type = 1) AS insert, 
            countIf(event_type = 2) AS merge, 
            sumIf(length(merged_from), event_type = 2) AS merge_parts 
        FROM system.part_log 
        WHERE (table = 'xx_local')  -- 替换为实际表名
          AND (event_date = today()) 
        GROUP BY h 
        ORDER BY h;
        

        正常情况下，insert 数量应小于 merge_parts 数量。若 insert 远大于 merge_parts，说明合并可能存在异常。

     2. 排查合并任务报错。

        SELECT event_time, exception 
        FROM system.part_log 
        WHERE table = 'xx_local'  -- 替换为实际表名
          AND event_type = 2 
          AND exception != '' 
        ORDER BY event_time DESC 
        LIMIT 10;
        

     3. 检查合并任务执行状态。

        SELECT
            event_time,
            event_type,
            current_parts,
            source_parts_in_new_tasks,
            duration_us
        FROM system.part_merge_log
        WHERE (table = 'xx_local')  -- 替换为实际表名
          AND (event_date = today())
        ORDER BY event_time DESC
        LIMIT 20;
        

   • 原因二：小 part 过多（写入方式不合理）
     若数据一次写入分区过多导致大量小 part，需优化数据写入策略，可参考 Kafka 消息积压。

查询成功率

使用 SQL 诊断功能定位指定时间段的查询失败 SQL，识别和分析查询失败原因，优先解决高频查询失败 SQL，将查询成功率提升至可接受水平。SQL 诊断功能使用说明请参见SQL 诊断。
查看失败 Query 明细，根据失败原因排查问题。其中，常见失败原因如下：

• Query、user、服务级别内存超限
• 数据库、表不存在
• SQL 语法错误
• Query 超时

写入成功率

执行以下命令，通过系统表 query_log 查询写入失败原因。实际使用时，请使用实际的时间段替换命令示例中的占位符。

SELECT query_id,
       query,
       event_time,
       exception,
       exception_code
FROM system.query_log
WHERE query_kind = 'Insert'
  AND event_time > 'xxx'
  AND event_time < 'xxx'
  AND exception != ''
LIMIT 100;

查看查询结果中的 exception 字段，获取失败原因，再根据失败原因排查。其中，常见失败原因如下：

• Query、user、服务级别内存超限
• 数据库、表不存在
• SQL 语法错误
• Query 超时

并发数

系统默认并发数上限 200，查看是否有长时间未执行完或卡住的查询，造成并发数异常，或针对高并发点查场景进行整体性能调优。

• 方式一：查看 query 并终止异常 query

  1. 查看当前正在运行的 query，查看是否有耗时比较长的 query 或者卡住的 query。

     SELECT * FROM system.processes
     

  2. 如果存在异常 query，可执行以下命令，终止 query。

     KILL query where query_id=xxx
     

• 方式二：性能调优
  对于高并发点查场景，可对 query 进行性能调优，详情请参考ByteHouse 高并发点查询调优最佳实践。

数据变更执行时间

为解决数据变更执行时间过长的异常问题，可按以下步骤处理：

1. 查询系统表 system.mutations，确认执行时间长的数据变更：

   SELECT *
   FROM system.mutations
   WHERE is_done = 0;
   

2. 检查该 mutation 对应的任务（如数据删除、表结构修改等）是否已实际完成，验证相关数据或表结构的变更状态：

   • 若变更已完成，直接终止该 mutation；
   • 若变更未完成且 mutation 已停止执行，同样终止该 mutation 后，重新发起数据变更。
     终止 mutation 的命令示例如下，使用时请使用实际的 mutation_id 替换示例中的占位符：

   KILL MUTATION WHERE mutation_id = 'xxx';
   

Broken table

查询系统表 system.broken_tables 获取出现该异常的原因。

SELECT * FROM system.broken_tables;

示例：Zookeeper 上不存在该节点的数据，导致该表异常，需通过重新建表解决该问题。

查询哪些表没有 leader

查询系统表 system.ha_replicas、system.ha_unique_replicas 获取出现该异常的原因。查询命令示例如下，使用时请使用实际的集群名称替换示例中的占位符：

# 查询系统表 system.ha_unique_replicas
SELECT *
FROM clusterAllReplicas('集群名', system.ha_unique_replicas)
WHERE is_leader = 0;

# 查询系统表 system.ha_replicas
SELECT *
FROM clusterAllReplicas('集群名', system.ha_replicas)
WHERE is_leader = 0;

示例：Zookeeper 上不存在该表数据，导致表没有 leader，需通过重新建表解决该问题。

查看 MergeTree 表个数

您可通过以下命令查询集群中 MergeTree 表的个数。一个集群中的 MergeTree 表个数建议不要超过 2000。如果 MergeTree 表个数较多，建议删除一些无用的表。

SELECT count()
FROM system.tables
WHERE engine LIKE '%MergeTree%';

集群慢查询数量

查询系统表 system.query_log可定位慢查询，可结合相关指标分析原因并进行优化，具体步骤如下：

1. 筛选慢查询。查询耗时超过耗时秒数阈值的查询，您可使用 event_date 指定慢查询发生的日期。

   SELECT *
   FROM system.query_log
   WHERE (type> 1)
   AND (query_duration_ms > 慢查询的秒数 * 1000)
   AND event_date = today ();
   

2. 分析慢查询关联的负载情况。
   查看慢查询发生时间段内的 SQL 数量和负载水平，event_time 需替换为慢查询出现的具体时段。
   如果 toStartOfFiveMinute 时间粒度不合适，可尝试使用 toStartOfHour。
   除 query_duration_ms 外，还可结合 total_cpu_seconds、read_rows、read_bytes 等列综合评估查询复杂度。

   SELECT
   toStartOfFiveMinute (event_time) AS h,
   count (*),
   avg (query_duration_ms),
   min (query_duration_ms),
   max (query_duration_ms)
   FROM system.query_log
   WHERE event_time > '2023-12-22 14:30:00'
   AND event_time < '2023-12-31 14:30:00'
   GROUP BY h
   ORDER BY h DESC;
   

3. 复现慢查询。从系统表 query_log 中获取慢查询语句并重新执行，验证是否复现慢查询现象。
   注意参考原始慢查询记录中 Settings 列的参数（如是否开启优化器 enable_optimizer），重跑时需保持参数一致。

最大主备同步延迟表个数

查询系统表 system.ha_queue，查看队列的堆积情况，定位出现同步慢的表。

SELECT 
    database, table, type, count()  
FROM system.ha_queue  
GROUP BY database,table,type
ORDER BY count()

同时，通过监控查看查询（Query）并发数、合并（Merge）任务数、并发数等指标，判断当前集群写入压力是否增大。您可通过集群管理 > 目标集群名 > 监控告警 路径查看监控。
通常情况下，写入任务完成 5 分钟内，主备即可完成同步。如果对主备同步延迟要求更高，可以适当减少集群写入速率，或者联系 ByteHouse 售后团队协助处理。

分布式表延迟文件个数

您可通过以下步骤排查并解决问题：

1. 查看分布式表延迟文件相关信息。

SELECT * FROM system.distribution_queue

2. 检查字段 last_exception 是否存在异常值：
   • 若 last_exception 有值，可直接通过异常信息定位问题原因，针对性解决。
   • 若 last_exception 无值，建议联系 ByteHouse 售后支持团队进一步排查。

错误的数据变更个数

查询系统表 system.mutations 定位执行错误的变更任务：

SELECT * 
FROM system.mutations 
WHERE is_done = 0 
  AND latest_fail_reason != ''

通过上述查询可直接获取执行失败的 mutation 详情，包括具体错误原因（latest_fail_reason 字段），便于针对性分析和解决问题。

Kafka 消息积压

1. 查询 Kafka 相关日志信息：

   SELECT * FROM system.kafka_log ORDER BY event_time DESC LIMIT 10;
   

2. 检查是否有最新的 POLL 事件产生：

   • 如果存在最新 POLL 事件，说明消息积压是由于消息量激增导致消费速度跟不上生产速度。若为暂时性激增，可先观察；若生产速度持续高位，建议考虑扩容 ByteHouse 节点以提升消费能力。
   • 如果不存在最新 POLL 事件，建议联系 ByteHouse 售后支持团队进一步排查。

Kafka 消费错误数

1. 执行以下 SQL 查询获取 Kafka 相关操作的失败原因：

   SELECT * 
   FROM system.kafka_log 
   WHERE exception != '' 
   ORDER BY event_time DESC 
   LIMIT 10;
   

2. 根据查询结果中 exception 字段的具体错误信息，分析问题根源并进行针对性处理。

磁盘占用率较昨日增长 xx%

您可执行以下命令，定位磁盘占用增长的主要来源。使用时请使用实际的数据库、表信息替换示例中的占位符或示例内容。

1. 通过集群管理 > 目标集群名 > 监控告警 路径查看云监控，查看集群增长曲线详情。
   

2. 查询高磁盘占用表：

   SELECT 
     database,
     table,
     formatReadableSize(sum(bytes_on_disk))
   FROM system.parts
   WHERE active
   GROUP BY database, table
   ORDER BY sum(bytes_on_disk) DESC
   LIMIT 20;
   

3. 查看特定表的分区占用情况：

   SELECT 
     partition_id,
     formatReadableSize(sum(bytes_on_disk))
   FROM system.parts
   WHERE database = 'xxx' 
     AND table = 'xxx' 
     AND active
   GROUP BY partition_id
   ORDER BY partition_id DESC
   LIMIT 50;
   

通过以上步骤可定位磁盘占用增长的主要来源（特定表或分区），为后续清理或扩容提供依据。

CPU 使用率较昨日增长 xx%

您可执行以下命令，定位高 CPU 消耗的 SQL 或查询模式。使用时请使用实际的集群信息、数据库名称、表名称、时间信息替换示例中的占位符或示例内容。

1. 执行以下命令，查找高 CPU 消耗的查询模式（normalized_query_hash）。

   SELECT
       normalized_query_hash,
       sum(cpu_s),
       sum(io),
       sum(mem),
       count() AS count,
       sum(sub_query_count),
       avg(query_duration_ms),
       any(query),
       groupArray(query_start_times)
   FROM 
   (
       SELECT
           any(if(is_initial_query, query, null)) AS query,
           groupArray(if(is_initial_query, query_start_time, null)) AS query_start_times,
           initial_query_id,
           max(if(is_initial_query, normalized_query_hash, 0)) AS normalized_query_hash,
           max(if(is_initial_query, query_duration_ms, 0)) AS query_duration_ms,
           count(1) AS sub_query_count,
           sum(total_cpu_seconds) AS cpu_s,
           sum(io_wait_seconds) AS io,
           sum(memory_usage) AS mem
       FROM cluster({cluster_name}, system.query_log, (1, 2))
       WHERE (event_date = '2024-12-23') AND (query_start_time > '2024-12-23 06:00:00') AND (query_start_time < '2024-12-23 06:05:00') AND (type != 1)
       GROUP BY initial_query_id
   )
   GROUP BY normalized_query_hash
   ORDER BY sum(cpu_s) DESC
   LIMIT 1
   

2. 查询该 normalized_query_hash 对应的全部 SQL 分布，定位高 CPU 消耗的具体 SQL。

   SELECT user,
          query,
          query_start_time
   FROM cluster({cluster_name}, system.query_log, (1, 2))
   WHERE (event_date = '2025-01-09')
     AND (query_start_time > '2025-01-09 15:00:00')
     AND (query_start_time < '2025-01-09 16:06:00')
     AND (type != 1)
     AND normalized_query_hash = xxxxxxxxxxxxxxxxxxx;
   

内存使用率较昨日增长 xx%

您可执行以下命令，查询缓存使用情况。使用时请使用实际的集群信息、数据库名称、表名称、时间信息替换示例中的占位符或示例内容。

1. 查询当前内存使用情况。

   SELECT query, formatReadableSize(memory_usage) 
   FROM system.processes 
   ORDER BY memory_usage DESC;
   

2. 查看 Merge 操作的内存使用情况。

   SELECT database, 
          table, 
          source_part_names, 
          formatReadableSize(memory_usage) 
   FROM system.merges;
   \G
   

3. 查询缓存相关内存使用情况。

   SELECT *, formatReadableSize(value)  
   FROM system.asynchronous_metrics 
   WHERE metric LIKE '%Cache%' 
   ORDER BY metric;
   

4. 查看 ClickHouse 整体内存使用情况。

   SELECT metric, formatReadableSize(value) 
   FROM system.metrics 
   WHERE metric = 'MemoryTracking';
   

5. 临时清理非压缩缓存（内存紧张时适用）。

   SYSTEM DROP UNCOMPRESSED CACHE;
   

6. 查询历史缓存使用趋势。

   -- 非压缩缓存历史情况
   SELECT
       toStartOfFiveMinute(event_time) AS fm,
       formatReadableSize(max(value))
   FROM system.asynchronous_metric_log
   WHERE metric = 'UncompressedCacheBytes' 
     AND event_date = today()
   GROUP BY fm
   ORDER BY fm ASC;
   
   -- 唯一键索引块缓存历史情况
   SELECT 
       toStartOfFiveMinute(event_time) AS fm, 
       formatReadableSize(max(value))  
   FROM system.asynchronous_metric_log 
   WHERE metric = 'UniqueKeyIndexBlockCacheBytes' 
     AND event_date = today() 
   GROUP BY fm 
   ORDER BY fm;
   
   -- 指定时间段的缓存情况
   SELECT 
       toStartOfFiveMinute(event_time) AS fm,
       lower(metric), 
       formatReadableSize(max(value))  
   FROM system.asynchronous_metric_log 
   WHERE lower(metric) LIKE '%cache%'  
     AND event_date = '' 
     AND event_time > '' 
     AND event_time < '' 
   GROUP BY fm, lower(metric) 
   ORDER BY fm;
   

P95 耗时较昨日增长 xx%

您可执行以下命令，定位慢查询。使用时请使用实际的时间信息替换示例内容。

1. 筛选超过阈值的慢查询。

   SELECT *
   FROM system.query_log
   WHERE (type > 1) 
     AND (query_duration_ms > 慢查询的秒数 * 1000) 
     AND event_date = today();
   

2. 分析慢查询时间段的负载情况。

   SELECT 
       toStartOfFiveMinute(event_time) AS h, 
       count(*),
       avg(query_duration_ms),
       min(query_duration_ms),
       max(query_duration_ms) 
   FROM system.query_log  
   WHERE event_time > '2023-12-22 14:30:00' 
     AND event_time < '2023-12-22 14:30:00'  
   GROUP BY h 
   ORDER BY h DESC;
   

   若5分钟粒度太细，可替换为toStartOfHour。
   除 query_duration_ms 外，还可结合 total_cpu_seconds、read_rows、read_bytes 等指标综合评估查询复杂度。

3. 复现慢查询。
   从 query_log 中获取慢查询语句重新执行，验证是否复现慢查询现象。注意参考原始慢查询记录中 Settings 列的参数（如是否开启优化器 enable_optimizer），重跑时需保持参数一致。

集群 QPS 较昨日增长 xx%

您可通过集群管理 > 目标集群名 > 监控告警 路径查看云监控，查看集群 QPS 变化趋势，观察其是否符合预期。