全部產品
Search
文件中心

E-MapReduce:常見問題

更新時間:Jan 06, 2026

本文匯總了使用EMR Serverless StarRocks時的常見問題。

如何跨帳號訪問OSS?

在使用Serverless StarRocks進行資料匯入或資料湖操作時,您可能需要訪問不同阿里雲賬戶下的OSS資源。預設情況下,Serverless StarRocks已配置為對當前賬戶下的OSS Bucket提供無密碼的自動存取權限。如果您需要訪問其他賬戶下的OSS資源,則需先取消當前的預設設定,並手動設定目標賬戶的存取金鑰,然後提交參數以使配置生效。

  1. 禁用現有免密訪問:在參數配置頁簽的以下檔案中,刪除配置項的值,保持配置項內容為空白。

    • core-site.xml

      fs.oss.credentials.provider =
    • jindosdk.cfg

      fs.oss.provider.format =
      fs.oss.provider.endpoint =
  2. 添加目標帳號的AccessKey:在參數配置頁簽,單擊新增配置項,在以下檔案中添加下列配置資訊。

    • core-site.xml

      fs.oss.accessKeyId = 目標帳號的AccessKey ID
      fs.oss.accessKeySecret = 目標帳號的AccessKey Secret
    • jindosdk.cfg

      fs.oss.accessKeyId = 目標帳號的AccessKey ID
      fs.oss.accessKeySecret = 目標帳號的AccessKey Secret
  3. 使配置項生效:在參數配置頁簽,單擊提交參數

如何使用UDF和JDBC連接器驅動?

在使用UDF和JDBC驅動前,您需要從外部擷取相應的JAR檔案。

  1. 上傳JAR檔案至OSS,詳情請參見上傳檔案

    在上傳檔案時,請將檔案 ACL設定為公用讀寫,以確保上傳的JAR檔案具備公用讀寫許可權。

  2. 擷取JAR檔案的URL。

    對於每個成功上傳的JAR檔案,在OSS控制台上找到它對應的連結地址。請使用內部網路Endpoint的HTTP URL,格式如下:

    • 對於JDBC驅動:http://<YourBucketName>.oss-cn-xxxx-internal.aliyuncs.com/mysql-connector-java-*.jar

    • 對於UDF:http://<YourBucketName>.oss-cn-xxxx-internal.aliyuncs.com/<YourPath>/<jar_package_name>

  3. 使用JAR檔案,詳情請參見Java UDFJDBC Catalog

如何重設執行個體的密碼?

重要
  • 重設執行個體的密碼將導致用戶端與服務端串連中斷,因此請務必在業務低峰期對生產環境進行此操作。

  • 僅具備AliyunEMRStarRocksFullAccess許可權的使用者才能執行密碼重設操作。

  1. 進入執行個體詳情頁面。

    1. 登入E-MapReduce控制台

    2. 在左側導覽列,選擇EMR Serverless > StarRocks

    3. 單擊目標執行個體的名稱。

  2. 執行個體詳情頁面,單擊基礎資訊地區的重設密碼

  3. 在彈出的對話方塊中,輸入新密碼和確認密碼,單擊確定

為什麼向Paimon表寫入資料時報錯?

  • 問題現象:在使用StarRocks向Paimon表寫入資料時,可能會遇到以下錯誤資訊。

    (5025, 'Backend node not found. Check if any backend node is down.')
  • 問題原因:Paimon表的許可權檢查機制可能導致StarRocks在進行寫入操作時無法正確識別後端節點。

  • 解決方案:

    • 升級版本(推薦方式) 如果您使用的版本低於下述版本,請您升級小版本,以更新至最新版本並獲得修複。

      • StarRocks 3.2版本:3.2.11-1.89 及以上

      • StarRocks 3.3版本:3.3.8-1.88 及以上

    • 臨時解決方案 在StarRocks執行個體的參數配置頁簽中的 core-site.xml 設定檔中添加以下配置項。

      dlf.permission.clientCheck=false

在StarRocks中建立外表時提示not a RAM user錯誤,該如何處理?

  • 問題現象:在StarRocks中嘗試通過外部表格功能建立外表時,可能會遇到以下錯誤資訊。

    current user is not a RAM user
  • 問題原因:許可權不足或者執行個體版本較低。

  • 解決方案:

    1. 首先檢查RAM帳號許可權:確保使用的RAM帳號具有對StarRocks的操作許可權,詳情請參見為RAM使用者授權

    2. 如果許可權無誤,請在StarRocks執行個體的執行個體詳情頁面,檢查並升級核心版本。

      如果您使用的版本低於以下版本,請您升級小版本,以更新至最新版本並獲得修複。

      • StarRocks 3.2版本:3.2.11-1.89 及以上

      • StarRocks 3.3版本:3.3.8-1.88 及以上

為什麼在SQL Editor中執行包含分號的SQL時會報錯?

  • 問題現象:在SQL Editor中執行包含分號(;)的SQL時報錯,報錯資訊包含the most similar input is {a legal identifier}

    image

  • 問題原因:因為SQL Editor預設將分號(;)作為語句結束符。如果您的SQL語句中包含分號(;),則會導致文法解析錯誤。

  • 解決方案:

    1. 設定自訂分隔字元。

      在執行包含分號的SQL語句前,設定一個自訂分隔字元,以避免文法解析錯誤。例如,改為$$

      delimiter $$
    2. 執行包含分號的SQL語句。本文樣本如下所示。

      INSERT INTO sr_test VALUES 
      (1, 'asdsd,asdsads'), 
      (2, 'sadsad;asdsads');
    3. 恢複預設分隔符號。

      在執行完SQL語句後,恢複預設的分隔字元(;),以便後續的SQL操作可以正常使用。

      delimiter ;
    4. 驗證結果。

      執行查詢語句驗證資料是否正確插入。

      image

為什麼Serverless StarRocks在匯入資料或訪問外表時失敗?

  • 問題現象:在使用Serverless StarRocks進行資料匯入或訪問外部表格時,如果目標地址為公網地址,可能會遇到匯入失敗或串連失敗的問題。

  • 原因分析:Serverless StarRocks執行個體預設運行在Virtual Private Cloud環境中,該環境可能不具備直接存取公網的能力。因此,當需要訪問公網資源(如匯入資料或查詢外部表格)時,若未配置公網訪問能力,請求將無法成功。

  • 解決方案:您可以通過在VPC中部署公網NAT Gateway並啟用SNAT功能,使Serverless StarRocks執行個體能夠通過該網關訪問公網資源。更多資訊,請參見使用公網NAT GatewaySNAT功能訪問互連網

如何避免StarRocks執行個體中的CLB/SLB因串連空閑逾時而關閉用戶端串連?

  • 問題現象:在StarRocks執行個體中,當FE節點數大於1時,可以通過開通SLB(Server Load Balancer)實現負載平衡,詳情請參見管理網關。當StarRocks執行個體開啟SLB後,若SQL查詢執行時間超過900秒,用戶端與SLB之間的串連會被強制斷開,導致查詢結果無法返回。

  • 問題原因:SLB的TCP串連存在一個最大空閑逾時時間(900 秒)。如果用戶端與SLB之間的串連在900秒內沒有資料轉送(例如,執行長時間啟動並執行SQL查詢),SLB會主動關閉該串連。這會導致用戶端在等待StarRocks響應時出現串連中斷的問題。

  • 解決方案:通過設定用戶端的TCP Keepalive參數以維持用戶端和SLB之間的串連,避免串連空閑逾時關閉。

    • 全域核心參數設定(系統級)

      通過修改作業系統的核心參數,為所有TCP串連啟用並配置合理的TCP Keepalive參數,以檢測網路連接的存活狀態。以下是需要設定的參數及其具體含義。

      參數

      含義

      建議值

      • Linux系統:net.ipv4.tcp_keepalive_time

      • FreeBSD/macOS:net.inet.tcp.keepidle

      串連空閑多久後發送第一個Keepalive探測包(單位:秒)。

      600秒

      • Linux系統:net.ipv4.tcp_keepalive_intvl

      • FreeBSD/macOS:net.inet.tcp.keepintvl

      Keepalive探測包的重傳間隔(單位:秒)。

      60秒

      • Linux系統:net.ipv4.tcp_keepalive_probes

      • FreeBSD/macOS:net.inet.tcp.keepcnt

      探測包連續發送失敗的次數,達到此值後中斷連線。

      5次

      Linux系統

      • 臨時生效

        # 設定全域Keepalive參數(需要root許可權)
        sudo sysctl -w net.ipv4.tcp_keepalive_time=600   # 對應keepidle(600秒)
        sudo sysctl -w net.ipv4.tcp_keepalive_intvl=60   # 對應keepintvl(60秒)
        sudo sysctl -w net.ipv4.tcp_keepalive_probes=5   # 對應keepcount(5次)
      • 永久生效

        將以下內容添加到/etc/sysctl.conf,並執行sysctl -p生效。

        echo "net.ipv4.tcp_keepalive_time = 600" >> /etc/sysctl.conf
        echo "net.ipv4.tcp_keepalive_intvl = 60" >> /etc/sysctl.conf
        echo "net.ipv4.tcp_keepalive_probes = 5" >> /etc/sysctl.conf

      FreeBSD/macOS系統

      • 臨時生效

        # 設定全域Keepalive參數(需要root許可權)
        sudo sysctl -w net.inet.tcp.keepidle=600
        sudo sysctl -w net.inet.tcp.keepintvl=60
        sudo sysctl -w net.inet.tcp.keepcnt=5
      • 永久生效

        將以下內容添加到/etc/sysctl.conf

        echo "net.inet.tcp.keepidle = 600" >> /etc/sysctl.conf
        echo "net.inet.tcp.keepintvl = 60" >> /etc/sysctl.conf
        echo "net.inet.tcp.keepcnt = 5" >> /etc/sysctl.conf
    • 程式設計語言適配(應用級)

      通過語言特定的API設定單個串連的TCP Keepalive參數。

      Java

      Java標準庫對TCP Keepalive的支援有限,但可以通過反射或底層Socket選項實現。

      說明

      以下代碼依賴於系統(如Linux/FreeBSD)對 tcp_keepidle等選項的支援。此外,部分方法(如反射)可能因JVM版本差異而失效,建議在實際使用前進行相容性測試。

      import java.io.IOException;
      import java.net.InetSocketAddress;
      import java.net.Socket;
      import java.net.SocketOption;
      import java.nio.channels.SocketChannel;
      
      public class TcpKeepaliveExample {
      
          public static void main(String[ ] args) {
      
              try (Socket socket = new Socket()) {
                  // 1. 啟用 Keepalive
                  socket.setKeepAlive(true);
      
                  // 2. 設定 Keepalive 參數(需通過底層 Socket 選項)
                  SocketChannel channel = socket.getChannel();
                  if (channel != null) {
                      // 設定 Keepidle(空閑時間)
                      channel.setOption(StandardSocketOptions.SO_KEEPALIVE, true); // 必須先啟用 Keepalive
                      setSocketOptionInt(socket, "tcp_keepidle", 600); // 需要系統支援
      
                      // 設定 Keepintvl(重傳間隔)
                      setSocketOptionInt(socket, "tcp_keepintvl", 60);
      
                      // 設定 Keepcount(失敗次數)
                      setSocketOptionInt(socket, "tcp_keepcnt", 5); // 注意:參數名可能因系統而異
                  }
      
                  // 串連到伺服器
                  socket.connect(new InetSocketAddress("example.com", 80));
                  // ... 其他動作 ...
              } catch (IOException e) {
                  e.printStackTrace();
              }
          }
      
          // 通過反射設定系統特定的 Socket 選項(如 Linux/FreeBSD)
          private static void setSocketOptionInt(Socket socket, String optionName, int value) {
              try {
                  Class<?> clazz = Class.forName("java.net.Socket$SocketOptions");
                  Object options = clazz.getDeclaredMethod("options").invoke(socket);
                  Class<?> optionsClass = options.getClass();
                  optionsClass.getDeclaredMethod("setOption", String.class, int.class)
                          .invoke(options, optionName, value);
              } catch (Exception e) {
                  throw new RuntimeException("Failed to set socket option " + optionName, e);
              }
          }
      }

      Python

      Python的socket模組支援直接配置TCP Keepalive參數。

      說明

      不同作業系統可能使用不同的參數名稱(例如,macOS可能需用TCP_KEEPALIVE代替TCP_KEEPIDLE),且部分參數可能需要root許可權才能進行設定。

      import socket
      
      def create_keepalive_socket():
          sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
          
          # 1. 啟用 Keepalive
          sock.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1)
          
          # 2. 設定 Keepalive 參數(Linux/FreeBSD)
          # Keepidle: 600秒
          sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPIDLE, 600)
          
          # Keepintvl: 60秒
          sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPINTVL, 60)
          
          # Keepcount: 5次
          sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPCNT, 5)
          
          return sock
      
      # 使用樣本
      sock = create_keepalive_socket()
      sock.connect(("example.com", 80))
      # ... 其他動作 ...
      sock.close()

      Golang

      Golang的net包提供了基礎的Keepalive配置,但需通過底層的syscall包設定詳細參數。

      說明

      不同作業系統可能使用不同的參數名稱,且部分參數可能需要root許可權才能進行設定。

      package main
      
      import (
          "fmt"
          "net"
          "syscall"
      )
      
      func main() {
          // 建立 TCP 串連
          conn, err := net.Dial("tcp", "example.com:80")
          if err != nil {
              panic(err)
          }
          defer conn.Close()
      
          // 擷取底層檔案描述符
          fd := conn.(*net.TCPConn).SyscallConn()
      
          // 設定 Keepalive 參數
          fd.Control(func(fdPtr *net.FileDesc) {
              fd := fdPtr.File
              // 啟用 Keepalive
              err = syscall.SetsockoptInt(int(fd), syscall.IPPROTO_TCP, syscall.TCP_KEEPALIVE, 1)
              if err != nil {
                  panic(err)
              }
      
              // 設定 Keepidle(空閑時間)
              err = syscall.SetsockoptInt(int(fd), syscall.SOL_TCP, syscall.TCP_KEEPIDLE, 600)
              if err != nil {
                  panic(err)
              }
      
              // 設定 Keepintvl(重傳間隔)
              err = syscall.SetsockoptInt(int(fd), syscall.SOL_TCP, syscall.TCP_KEEPINTVL, 60)
              if err != nil {
                  panic(err)
              }
      
              // 設定 Keepcount(失敗次數)
              err = syscall.SetsockoptInt(int(fd), syscall.SOL_TCP, syscall.TCP_KEEPCNT, 5)
              if err != nil {
                  panic(err)
              }
          })
      
          // ... 其他動作 ...
      }

StarRocks備份資料報錯Unexpected exception: Table '' is not a OLAP table

  • 問題現象:在使用StarRocks進行資料快照備份時,遇到以下報錯資訊。

    Unexpected exception: Table '<table_name>' is not a OLAP table
  • 原因分析:

    • 執行個體為存算分離模式

      StarRocks存算分離執行個體不支援資料備份和恢複功能,僅存算一體執行個體支援此功能。

    • 表引擎類型不相容

      StarRocks的備份功能僅支援OLAP引擎的表。如果表的引擎類型不是OLAP,則會觸發該報錯。

  • 解決方案:

    • 查看執行個體類型。

      在StarRocks的執行個體列表中,查看執行個體類型。如果執行個體為存算分離版,則不支援資料備份和恢複功能。建議您使用存算一體執行個體以啟用備份和恢複功能。更多資訊,請參見備份與恢複(Beta)

    • 檢查表引擎類型。

      檢查目標表的DDL定義,確認是否設定了ENGINE=OLAP

      SHOW CREATE TABLE <table_name>;

      如果表的引擎不是OLAP,請根據業務需求重新建立表,並確保指定ENGINE=OLAP

主鍵模型匯入報錯:msg:Cancelled, msg: Primary-key index exceeds the limit

  • 問題現象:

    在主鍵模型寫入資料時,報錯如下:
    msg: Cancelled, msg: Primary-key index exceeds the limit. tablet_id: 2506733, consumption: 33176971421, limit: 32116807950. Memory stats of top five tablets: 3656508(4465M) 3656496(4464M) 3656544(4464M) 3656520(4462M) 3656532(4461M): be: backend-0.backend.xxx.svc.cluster.local.xxx

  • 排查思路:

    • 分析當前 BE 節點記憶體使用量情況,確認是否存在資源瓶頸。

    • 判斷叢集類型(存算一體 or 存算分離),並檢查對應配置項。

  • 詳細排查步驟:

    • 分析記憶體使用量

      • 報錯的根本原因是:主鍵索引記憶體消耗超過了 BE 節點的記憶體上限(limit)。

      • 查看 BE 節點的 mem_limit 配置(可通過 SHOW FRONTENDS 或 SHOW BACKENDS 擷取),評估其可用記憶體容量。

    • 解決方案

      • 解法一:啟用持久化索引(推薦)

        • 存算一體:將 enable_persistent_index 設定為 true

        • 存算分離:將 persistent_index_type 設定為 cloud_native

      • 解法二:合理分區設計

        • 對主鍵表進行合理的分區(如按時間、地區等維度),避免全表寫入。

        • 分區後,每次寫入僅影響部分分區,主鍵索引只需載入對應分區的資料,從而降低單次寫入的記憶體壓力。

匯入任務報錯:[E1008]Reached timeout=xxx ms

  • 問題現象:

    • 業務 Flink 任務向 StarRocks 匯入資料時,報錯:
      Message: [E1008] Reached timeout=7500ms @x.x.x.x:8060

    • 業務通過 INSERT INTO 方式匯入資料時,報錯:
      java.sql.SQLException: [E1008] Reached timeout=7500ms @10.106.7.182:8060

  • 排查思路:

    • 若報錯中的逾時值 不等於 30000ms(即預設的 rpc_connect_timeout_ms),需確認是否手動調整過 BE 節點的 rpc_connect_timeout_ms 參數(預設值為 30000ms);

    • 對於 INSERT INTO 類型的匯入任務,需確認是否設定了 query_timeout 參數(例如 query_timeout = 15)。當前 StarRocks 的內部邏輯會將 RPC 逾時閾值設為 query_timeout 的一半(單位:ms),因此若 query_timeout=15,則對應逾時為 7500ms。

  • 詳細排查步驟:

    • 如確認修改了 BE 的 rpc_connect_timeout_ms 參數。建議恢複為預設值(30000ms),避免因過短的連線逾時引發誤判。

    • 報錯中 Reached timeout=7500ms 通常表明 BE 節點的 brpc 線程負載較高,導致 RPC 請求處理延遲,進而觸發逾時。

    • 通過分析目標表的資料分布情況:SHOW TABLET FROM 目標資料庫.目標表 ORDER BY RowCount DESC;以確認業務表的Tablet資料分布是否合理。例如,單個Tablet的資料量若遠超最佳實務推薦範圍(1GB ~ 10GB),將導致部分BE節點的負載過高,從而影響寫入效能。

    • 解決方案

      • 解法一(推薦)
        最佳化表的分桶策略,重新選擇合適的 高基數(High Cardinality)欄位 作為 DISTRIBUTED BY HASH(...) 的分桶鍵,使資料在 Tablet 間均勻分布。

      • 解法二(臨時緩解)
        在 BE 節點 CPU 和 I/O 負載未達瓶頸 的前提下,可適當調優以下參數:

        • 增大 brpc_num_threads:預設值為 BE CPU 核心數,可嘗試調整為 2 倍或 4 倍(不建議超過 4 倍,以免線程競爭加劇);

        • 增大 flush_thread_num_per_store:預設值為 2,可調整為 4,以提升資料刷盤並發能力。

匯入任務報“Error:NULL value in non-nullable column 'xxx'”錯誤

  • 問題現象:向 StarRocks 表匯入資料時,出現如下錯誤:Error: NULL value in non-nullable column 'xxx'

  • 問題原因:向定義為 NOT NULL 的列寫入了 NULL 值,違反了表結構約束,導致匯入任務失敗。

  • 解決方案

    • 方案一:修複上遊資料

      在資料寫入 StarRocks 前,過濾或填充 NULL 值,確保符合目標資料表條件約束。

    • 方案二:調整表結構

      若商務邏輯確實允許該欄位為空白,建議修改表結構,移除 NOT NULL 約束。

Flink connector資料匯入報because of too many versions, current/limit: 1009/1000錯誤

  • 問題現象:

    通過 Flink Connector 向 StarRocks 表持續寫入資料,出現如下報錯:because of too many versions, current/limit: 1009/1000

  • 問題原因:在 StarRocks 的主鍵模型(Primary Key Model)或更新模型(Unique Key with Merge-on-Write)中,每次資料匯入都會產生一個新版本。為防止中繼資料膨脹並保證查詢效能,系統預設限制每個分區最多保留 1000 個版本。

  • 解決方案

    • 檢查分區 Compaction Score。

      執行以下 SQL,查看目標表各分區的 Compaction 壓力:

      SELECT 
          TABLE_NAME,
          PARTITION_NAME,
          AvgCS AS avg_compaction_score,
          MaxCS AS max_compaction_score
      FROM information_schema.partitions_meta 
      WHERE TABLE_NAME = 'your_table_name';

      報錯分區的 MaxCS(最大 Compaction Score)遠高於 100,說明存在大量待合并的小版本,Compaction 未能及時完成。

    • 手動觸發 Compaction。

      執行ALTER TABLE your_db.your_table COMPACT PARTITION your_partition_name;

    • 最佳化 Flink 寫入參數。

      調大Flink側的sink參數,包括sink.buffer-flush.max-bytessink.buffer-flush.max-rowssink.buffer-flush.interval-ms,以減少匯入頻次,從而避免產生過多的小版本。

External Catalog方式查詢報Failed to get status for file xxx錯誤

  • 問題現象:

    查詢外部資料湖(如Paimon、Iceberg 等)中的表時,查詢報錯:
    (1064, 'Failed to get status for file: oss://data-lakehouse-oss-normal/dataware.db/dwd_annotation2_user/metadata/00097-10647858-814a-499e-b300-51c570ee7ee0.metadata.json')。OSS API 返回錯誤資訊:

    <Error>
      <Code>AccessDenied</Code>
      <Message>You have no right to access this object because of bucket acl.</Message>
      <RequestId>68EC744EB6CD8C3539FAB32A</RequestId>
      <HostId>data-lakehouse-oss-normal.oss-cn-shenzhen-internal.aliyuncs.com</HostId>
      <EC>0003-00000001</EC>
      <RecommendDoc>https://api.aliyun.com/troubleshoot?q=0003-00000001</RecommendDoc>
    </Error>
  • 問題原因:StarRocks 通過 External Catalog 功能查詢外部資料湖(如 Hive、Iceberg、Hudi 等)中的表,底層依賴對Object Storage Service(如阿里雲 OSS)的訪問能力。若許可權或配置不當,將導致中繼資料或資料檔案讀取失敗。

  • 解決方案

    • 首先驗證 AccessKey 有效性:確認所配置的 accessKeyId/accessKeySecret 能正常訪問目標 OSS Bucket。

    • 如果accessKeyId / accessKeySecret配置正確,請確認是否存在跨帳號訪問OSS Bucket的情況。對於跨帳號訪問OSS Bucket,需對以下配置進行修改,詳細操作請參見如何跨帳號訪問OSS?

如何查看cn、be節點硬碟上持久化索引佔用硬碟的大小?

在啟用持久化索引(enable_persistent_index = truepersistent_index_type = 'cloud_native')後,主鍵索引會落盤儲存。可通過 information_schema.be_tablets 表查詢其磁碟使用量。

-- 查詢表的索引大小資訊,按索引大小降序排列
SELECT 
    tables_config.TABLE_NAME,
    t1.TABLE_ID,
    t1.index_sum_mb
FROM (
    -- 計算每個表的索引總大小(MB)
    SELECT 
        TABLE_ID,
        SUM(INDEX_DISK)/1024/1024 AS index_sum_mb
    FROM information_schema.be_tablets 
    GROUP BY TABLE_ID
) t1 
JOIN tables_config ON tables_config.TABLE_ID = t1.TABLE_ID 
ORDER BY index_sum_mb DESC
-- 可選:添加LIMIT子句限制返回結果數量,避免資料量過大
-- LIMIT 100
;

如何查看錶正在寫入的事務以及不同txn寫入批次對應的tablet?

追蹤進行中或最近完成的匯入任務,定位具體寫入的 Tablet 分布。

SELECT 
    txn_table.*,
    tc.table_name
FROM (
    SELECT 
        bt.TABLET_ID,
        bt.COMMIT_TIME,
        bt.PUBLISH_TIME,
        bt.TABLE_ID
    FROM information_schema.be_txns bt
    JOIN information_schema.be_tablets btt 
        ON bt.TABLET_ID = btt.TABLET_ID
) AS txn_table
JOIN information_schema.tables_config tc 
    ON txn_table.TABLE_ID = tc.TABLE_ID;

分析某時間段內 CPU / 記憶體負載突增原因?

通過審計日誌(Audit Log)定位高資源消耗的查詢。

SELECT 
    queryId,
    timestamp,
    ROUND(memCostBytes / 1024 / 1024 / 1024, 2) AS memCostGB,
    cpuCostNs
FROM _starrocks_audit_db_.starrocks_audit_tbl
WHERE timestamp BETWEEN '2025-xx-xx hh:mm:ss' AND '2025-xx-xx hh:mm:ss'
ORDER BY cpuCostNs DESC, memCostGB DESC
LIMIT 20;

分析某時間段內 I/O 負載突增原因

I/O 峰值通常由大範圍掃描(如全表掃描、未命中分區/索引)引起。

SELECT 
    queryId,
    timestamp,
    ROUND(scanBytes / 1024 / 1024 / 1024, 2) AS scanTotalGB
FROM _starrocks_audit_db_.starrocks_audit_tbl
WHERE timestamp BETWEEN '2025-xx-xx hh:mm:ss' AND '2025-xx-xx hh:mm:ss'
ORDER BY scanTotalGB DESC
LIMIT 20;