生产环境中可能出现部分大查询耗尽整个集群资源的情况，这会影响其他查询的性能与可用性，需迅速定位最近占用资源较多的大查询或大作业并处理，以降低对业务的整体影响。本文将指导您如何快速定位并处理这些大查询。

大查询定位：运行结束大查询/作业 #

您可以通过 StarRocks 自身的审计日志进行诊断，对运行结束的作业进行定位，判断是否为需要治理的大查询作业。诊断时：

• 您可以主要关注 cpuCost、scanBytes、memCostBytes、queryTime 指标。

  说明

  cpuCost 可理解为占用的 CPU 时间片，例如集群为 8 * 48core，如果查询的 cpuCost = 3840秒，意味着需要将集群 CPU 打满 100% 持续 10s 才能查询结束。

• 通过以下查询可定位 Top 任务，同时结合调度周期 / SQL 进行优化。即，结合监控初步定位硬件资源的瓶颈（cpu/mem/disk），再根据审计日志表定为到 cpu/mem/disk 使用资源最大的 Top 任务。
  以下为 StarRocks 审计日志分析的示例代码。

  -- 统计 Insert/no-Insert 查询类型每小时的相关指标
  SELECT
      DATE_FORMAT(timestamp, '%Y-%m-%d %H:00:00') AS dt,
      CASE
          WHEN (stmt LIKE '%INSERT%' OR stmt LIKE '%insert%') THEN 'isInsert'
          ELSE 'isQuery'
      END AS `type`,
      ROUND(SUM(scanBytes / 1024 / 1024), 0) AS sum_scan_mb,
      ROUND(AVG(scanBytes / 1024 / 1024), 0) AS avg_scan_mb,
      ROUND(SUM(cpuCostNs / 1000 / 1000 / 1000), 0) AS sum_cpu_time_sec,
      ROUND(AVG(cpuCostNs / 1000 / 1000 / 1000), 0) AS avg_cpu_time_sec,
      ROUND(SUM(queryTime / 1000), 0) AS sum_query_time_sec,
      ROUND(AVG(queryTime / 1000), 0) AS avg_query_time_sec,
      COUNT(*) AS total_query_count
  FROM starrocks_audit_db__.starrocks_audit_tbl__
  WHERE timestamp BETWEEN '2025-06-19 00:00:00' AND '2025-06-25 23:59:00'
    AND stmt != 'SELECT 1'
    AND stmt NOT LIKE '%@@%'
    AND user != 'root'
  GROUP BY 1, 2
  ORDER BY 2, 1;
  
  -- 统计 cpuCost 最高的 SQL
  SELECTg BY cpuCostSec DESC LIMIT 50;
  
  -- 按 digest 统计 cpuCost（digest: sql 指纹，通常可以代表一类 sql，可以判断出用户的接口）
  -- Starrocks 需要开启 digest 功能才可以
  -- ADMIN SET FRONTEND CONFIG ("enable_sql_digest" = "true");
  -- https://docs.starrocks.io/docs/administration/sql_digest/
  
  WITH top_sql AS (
      SELECT
          digest,
          SUM(queryTime)
      FROM starrocks_audit_db__.starrocks_audit_tbl__
      GROUP BY digest
      ORDER BY SUM(queryTime) DESC
      LIMIT 10
  )
  SELECT *
  FROM starrocks_audit_db__.starrocks_audit_tbl__
  WHERE digest IN (SELECT digest FROM top_sql);
  

大查询定位：运行中大查询/作业 #

1. 查看当前查询的资源消耗，需重点关注结果中的ExecTime（查询运行时间）或 CPUTime（CPU占用时间）列，根据这些列的值识别资源消耗高的大查询。详情请参考：StarRocks 查看运行中的查询。

   -- 查看当前FE节点的连接以及查询任务
   SHOW PROCESSLIST;
   -- 查看所有FE节点的连接以及查询任务
   SHOW FULL PROCESSLIST;
   
   -- 作为观察参考
   SHOW PROC '/current_queries'; -- 查看当前FE节点正在运行的查询
   SHOW PROC '/global_current_queries'; -- 查看所有FE节点正在运行的查询
   

   返回结果通常包括以下几列。

   • QueryId
   • ConnectionId
   • Database：当前查询的DB
   • User：用戶
   • ScanBytes：当前已扫描的数据量
   • ProcessRow：当前已扫描的数据行数
   • CPUTime：当前查询已使用的CPU时间，单位秒。此为多个线程累加的CPU时间，举个例子，如果有两个线程分别占用1秒和2秒的CPU时间，那么累加起来的CPU时间为3秒
   • MemoryUsage：当前占用的内存。如果查询涉及到多个BE节点，此值为该查询在所有BE节点上占用内存之和
   • ExecTime：查询从发起到现在的时长

2. 终止 CPU 占用时间（CPUTime）较高的查询（query）。详情请参考：StarRocks Kill。

   -- kill对应processlist_id
   kill connection {processlist_id};
   

若无法快速定位大查询且需要迅速止损 #

1. 若无法快速定位运行中的大查询，建议重启BE以终止所有查询恢复整体业务。
2. 重启止损后，可参考 SQL诊断使用说明 或审计日志表对历史查询进行统计，结合业务排查大查询的来源并进行查询优化，详细操作请参考：查询调优最佳实践。

   -- 查看最近1h内CPU消耗最大的查询Top10
   SELECT * FROM starrocks_audit_db__.starrocks_audit_tbl__
   WHERE timestamp >= DATE_SUB(NOW(), INTERVAL 1 HOUR)
   ORDER BY cpuCostSec desc limit 10;