查詢限制

使用 版本 下拉選單切換服務。 了解更多關於導航的資訊。
Apply to： ✅ Microsoft Fabric ✅ Azure Data Explorer ✅ Azure Monitor ✅ Microsoft Sentinel

Kusto 是一個臨時查詢引擎，負責承載大型資料集，並嘗試透過將所有相關資料儲存在記憶體中來滿足查詢需求。 這本身就有風險，查詢會無限地壟斷服務資源。 Kusto 會以預設查詢限制的形式提供數個內建保護。 如果您考慮移除這些限制，請先藉由這麼做來判斷您是否實際取得任何值。

要求並行限制

請求並行 性是指同時執行多個請求的限制。

• 限制的預設值取決於資料庫執行中的 SKU，並計算為： Cores-Per-Node x 10。
  • 例如，針對在 D14v2 SKU 上設定的資料庫，其中每部電腦都有 16 個虛擬核心，預設限制為 16 cores x10 = 160。
• 你可以透過設定工作負載群組的default來更改預設值。
  • 多種因素會影響資料庫中可同時執行的請求數量。 最重要的因素是資料庫 SKU、資料庫的可用資源和使用模式。 根據在類似生產環境的使用模式進行負載測試來配置政策。

結果集大小的限制（結果截斷）

結果截斷 是查詢回傳結果集的預設限制。 Kusto 會將傳回給客戶端的記錄數目限制為 500,000，並將這些記錄的整體數據大小限製為 64 MB。 超過上述任一限制時，查詢會失敗並出現「部分查詢失敗」。 超過整體資料大小會產生異常，並顯示以下訊息：

The Kusto DataEngine has failed to execute a query: 'Query result set has exceeded the internal data size limit 67108864 (E_QUERY_RESULT_SET_TOO_LARGE).'

超過紀錄數則失敗，但有一個例外說明：

The Kusto DataEngine has failed to execute a query: 'Query result set has exceeded the internal record count limit 500000 (E_QUERY_RESULT_SET_TOO_LARGE).'

你可以用多種策略來解決這個錯誤。

• 藉由修改查詢來只傳回有趣的數據，以減少結果集大小。 當初始失敗查詢太「寬」時，此策略很有用。 例如，查詢不會投影不需要的數據行。
• 藉由將查詢后處理，例如匯總移轉到查詢本身，以減少結果集大小。 此策略適用於查詢輸出被送入另一個處理系統，該系統再進行其他聚合的情況。
• 當您想要從服務匯出大型數據集時，請從查詢切換為使用 數據匯出 。
• 指示服務透過以下 set 章節列出的語句或 客戶端請求屬性中的標記來抑制此查詢限制。

減少查詢所產生的結果集大小的方法包括：

• 使用 摘要運算子（summarize operator ）來將查詢輸出中類似的紀錄分組並彙總。 可能會使用 take_any 聚合函數來取樣某些數據行。
• 使用 take 運算符來取樣查詢輸出。
• 使用子字串函式來修剪寬的任意文字數據行。
• 使用項目運算符，從結果集卸除任何不感興趣的數據行。

您可以使用要求選項來停用結果截斷 notruncation 。 我們建議仍會實施某種形式的限制。

例如：

set notruncation;
MyTable | take 1000000

你也可以透過設定 truncationmaxsize （最大資料大小（位元組，預設為 64 MB）和 truncationmaxrecords （最大記錄數，預設為 500,000）來更細緻地控制結果截斷。 例如，以下查詢集會使截斷發生在 1,105 筆紀錄或 1 MB，以超過者為準。

set truncationmaxsize=1048576;
set truncationmaxrecords=1105;
MyTable | where User=="UserId1"

拿掉結果截斷限制表示您想要將大量數據移出 Kusto。

您可以使用 命令或稍後的匯總，移除導出目的 .export 的結果截斷限制。 如果您選擇稍後的匯總，請考慮使用 Kusto 進行匯總。

Kusto 提供許多客戶端函式庫，能透過串流方式處理「無限大」的結果。 使用其中一個連結庫，並將它設定為串流模式。 例如，使用 .NET Framework 用戶端 （Microsoft.Azure.Kusto.Data），並將 連接字串 的串流屬性設定為 true，或使用一律串流結果的 ExecuteQueryV2Async（） 呼叫。 如需如何使用 ExecuteQueryV2Async（）的範例，請參閱 HelloKustoV2 應用程式。

你也可能覺得 C# 串流擷取範例應用程式很有幫助。

默認會套用結果截斷，而不只是套用至傳回給客戶端的結果數據流。

設定多個結果截斷屬性

當你在set中使用語句或指定旗標時，會適用以下規則。

• 如果你設定 notruncation ，但同時設定 truncationmaxsize、 truncationmaxrecords或 query_take_max_records，服務會 notruncation忽略 。
• 如果你設定 truncationmaxsize、 或truncationmaxrecordsquery_take_max_records多次，服務會使用每個屬性的較低值。

查詢運算子所佔用的記憶體限制

你可以設定 每個迭代器的最大記憶體消耗 上限，來控制每個查詢運算子在每個節點所消耗的記憶體量。 有些查詢運算子，如 join 和 summarize，會保留大量資料在記憶體中。 透過提高請求選項 maxmemoryconsumptionperiterator的預設值，你可以執行需要每位運算元更多記憶體的查詢。

此請求選項的最大支援值為 32,212,254,720（30 GB）。 如果你多次設定 maxmemoryconsumptionperiterator ，例如在兩個客戶請求屬性中或使用 set 陳述式，較低的值就會適用。

當查詢達到設定的每位運算子記憶體上限時，會顯示部分查詢失敗訊息，並包含文字 E_RUNAWAY_QUERY。

例如：

The ClusterBy operator has exceeded the memory budget during evaluation. Results might be incorrect or incomplete (E_RUNAWAY_QUERY).

The HashJoin operator has exceeded the memory budget during evaluation. Results might be incorrect or incomplete (E_RUNAWAY_QUERY).

The Sort operator has exceeded the memory budget during evaluation. Results might be incorrect or incomplete (E_RUNAWAY_QUERY).

例如，此查詢設定每個迭代器的最大記憶體消耗為 15 GB：

set maxmemoryconsumptionperiterator=16106127360;
MyTable | summarize count() by Use

另一個可能觸發 E_RUNAWAY_QUERY 部分查詢失敗的限制是單一運算符所持有字串的最大累積大小。 前面提到的請求選項無法覆蓋這個限制。

Runaway query (E_RUNAWAY_QUERY). Aggregation over string column exceeded the memory budget of 8GB during evaluation.

超過此限制時，最可能相關的查詢運算子是 join、 summarize或 make-series。

為了繞過限制，修改查詢以使用 洗牌查詢 策略。 此變更也可能提升查詢的效能。

在所有情況下 E_RUNAWAY_QUERY，另一個選項（除了透過設定請求選項增加限制並改用洗牌策略來增加限制外）是切換到抽樣。 取樣減少查詢處理的資料量，從而減輕查詢運算子的記憶體壓力。

這兩個查詢說明了如何進行抽樣。 第一個查詢是使用隨機數產生器進行統計取樣。 第二個查詢是具決定性的取樣，方法是從數據集哈希某些數據行，通常是一些標識符。

T | where rand() < 0.1 | ...

T | where hash(UserId, 10) == 1 | ...

如需更多關於使用同時與 等summarizejoin機制hint.shufflekey的資訊，請參閱 Kusto 查詢語言查詢的最佳實務。

每個節點的記憶體限制

每節點查詢的最大記憶體也是防止查詢失控的另一個限制。 請求選項 max_memory_consumption_per_query_per_node 設定單一節點可用於特定查詢的記憶體上限。

set max_memory_consumption_per_query_per_node=68719476736;
MyTable | ...

如果你多次設定，例如同時在 max_memory_consumption_per_query_per_node 客戶請求屬性和一個 set 語句中，較低的值會適用。

如果查詢使用 summarize、 join或 make-series 運算子，您可以使用 隨機查詢 策略來降低單一計算機上的記憶體壓力。

限制執行逾時

伺服器逾時 是指服務端的逾時，服務會套用到所有請求。 Kusto 會在多個點強制執行執行請求（查詢與管理指令）逾時：

• 用戶端連結庫 （如果使用）
• 接受要求的服務端點
• 處理要求的服務引擎

預設情況下，查詢逾時為四分鐘，管理指令為十分鐘。 如果需要，你可以將這個數值增加，最多一小時。

• 各種用戶端工具支援變更逾時，作為其全域或每個連線設定的一部分。 例如，在 Kusto.Explorer 中，使用 Tools>Options>Connections>查詢伺服器逾時。
• 以程序設計方式，SDK 支援透過 servertimeout 屬性設定逾時。 例如，在 .NET SDK 中，透過 客戶端請求屬性設定此屬性，並設定型別 System.TimeSpan為 的值。

關於暫停的備註

• 在用戶端上，系統會從所建立的要求套用逾時，直到響應開始抵達客戶端為止。 在用戶端上讀取承載所需的時間不會被視為逾時的一部分。 這取決於呼叫端從數據流提取數據的速度。
• 此外，在用戶端上，所使用的實際逾時值略高於使用者所要求的伺服器逾時值。 這項差異是允許網路等待時間。
• 若要自動使用允許的要求逾時上限，請將用戶端要求屬性 norequesttimeout 設定為 true。

查詢 CPU 資源使用量的限制

Kusto 執行查詢並使用資料庫中所有可用的 CPU 資源。 如果同時執行多個查詢，它會嘗試在查詢間進行公平的輪詢。 此方法會產生查詢定義函式的最佳效能。 有時你可能會想限制特定查詢所用的 CPU 資源。 例如，如果你執行背景工作，系統可能會容忍較高的延遲，以給予並行內嵌查詢高優先權。

Kusto 支援在執行查詢時指定兩 個要求屬性 。 屬性是 query_fanout_threads_percent 和 query_fanout_nodes_percent。 這兩個屬性都是整數，預設為最大值（100），但你可以針對特定查詢將其縮小。

第一個特性 query_fanout_threads_percent控制線程使用的扇化因子。 當你將此屬性設為 100%時，查詢會使用每個節點上的所有 CPU。 例如，部署在 Azure D14 節點上的 16 個 CPU。 當你將此屬性設為 50%時，查詢會佔用一半的 CPU，依此類推。 數位會四捨五入為整個CPU，因此將屬性值設定為0是安全的。

第二個屬性 query_fanout_nodes_percent 控制每個子查詢分配操作中應使用多少查詢節點。 它會以類似的方式運作。

例如，如果你在客戶請求屬性和敘set述中多次設定 query_fanout_nodes_percent 或query_fanout_threads_percent，則每個屬性的較低值都會適用。

查詢複雜度的限制

在查詢執行期間，查詢文字會轉換成代表查詢的關係運算符樹狀結構。 若樹深度超過內部閾值，查詢過於複雜無法處理，並會因錯誤代碼而失敗。 失敗表示關係運算子樹狀結構超過其限制。

查詢複雜度超過了

查詢太複雜，引擎無法編譯。 這種複雜性通常發生在查詢計畫建構消耗過多資源時。 常見的原因包括：

• 跨多個資料表的大型聯集，例如在大型資料庫中使用 union * 。
• 深度巢式子查詢。
• 許多層次 let 的陳述彼此參照。

查詢計畫大小或複雜度超過設定限制

查詢產生的查詢計畫太大無法處理。 常見的原因包括：

• 廣播連接的左側產生過多資料。
• 返回的 toscalar() 結果太大了。
• 表達式內 in() 的結果太大。 例如，當子 in (subquery) 查詢回傳過多值時。

以下範例展示了常見的查詢模式，可能導致查詢超過這些限制而失敗：

• 一長串串連在一起的二元運算子。 例如：

T
| where Column == "value1" or
        Column == "value2" or
        .... or
        Column == "valueN"

針對此特定情況，請使用 in() 運算子重寫查詢。

T
| where Column in ("value1", "value2".... "valueN")

• 一個使用聯合運算子且執行過寬結構分析的查詢。 這個問題是因為預設的聯合會回傳了一個「外部」聯合結構。 此結構表示輸出包含底層資料表的所有欄位。

檢視查詢並減少查詢所使用的欄位數量。

相關內容

• 查詢最佳做法