執行或重設索引器、技能或文件

註

Azure AI 搜尋服務可透過 Azure 入口網站、REST API 及 Azure SDK 取得。它同時也是 Foundry IQ 的基礎，這是一個管理式知識層，能將企業內容轉化為可重複使用、權限感知的知識庫，供 Microsoft Foundry 入口網站中的代理使用。

在 Azure AI 搜尋服務中，你可以用幾種方式執行索引器：

索引器一建立就立即執行。除非你在停用狀態下建立索引器，否則此選項為預設值。
依照排程運行以定期地觸發執行。如果排程索引器停止觸發，請參閱排程行為常見問題解答以了解復原步驟。
按需運行，不管有沒有重置。

本文說明如何按需求執行索引器，包括有重置和無重置的情況。它也描述了索引器的執行、持續時間與並行性。

索引器如何連接 Azure 資源

索引器是少數會直接呼叫其他 Azure 資源的子系統之一。根據外部資料來源，你可以使用金鑰或角色來驗證連線。

就 Azure 角色而言，索引器沒有獨立的身份：搜尋引擎與另一個 Azure 資源的連線，使用搜尋服務的系統或使用者指派的管理身份，並對目標 Azure 資源進行角色指派。如果索引器連接到虛擬網路上的Azure資源，你應該為該連線建立一個共享私有連結。

註

索引器以服務層級權限運作，而非使用者權限。索引器可以寫入搜尋服務中的任何索引，即使你指定角色限制對特定索引的存取。欲了解更多資訊，請參閱「按索引範圍與索引器操作」。

索引器運行

搜尋服務會為每個搜尋單元執行一個索引工作。每個搜尋服務起初都只有一個搜尋單元，但每新增一個分割區或副本，服務的搜尋單元數量都會增加。您可以在 Azure 入口網站的概覽頁面的基本資訊區查看搜尋單位數。若需同時處理，請確保搜尋單元包含足夠的副本。索引器不會在背景執行，因此如果服務承受壓力，您可能會遇到比平常更多的查詢節流。

以下截圖顯示搜尋單元數量，決定同時可執行多少索引器。

一旦索引器執行開始，你就無法暫停或停止它。當沒有更多文件可載入或刷新，或達到最大執行時間限制時，索引器執行會停止。

你可以同時執行多個索引器，前提是容量足夠，但每個索引器本身是單一實例。在索引器已執行中啟動新實例會產生以下錯誤： "Failed to run indexer "<indexer name>" error: "Another indexer invocation is currently in progress; concurrent invocations are not allowed."

索引器執行環境

索引器工作是在受管理的執行環境中執行。目前有兩種環境：

私有執行環境運行於專屬於你的搜尋服務的搜尋叢集上。
多租戶環境有內容處理器，Microsoft 負責管理與保護，且不需額外付費。此環境卸下計算密集的處理能力，使服務專屬資源仍可用於例行操作。只要可行，大多數技能都會在多租用戶環境中執行。這個環境是預設的。

計算密集型處理 指的是運行於內容處理器與索引工作上的技能組，這些工作處理大量文件或大型文件。啟發學習法與系統資訊會決定多租用戶內容處理器上的非技能處理方式，且不受客戶控制。

您可以將索引器和技能處理專門關聯到您的搜尋叢集，避免 Standard2 或更高層級的服務使用多租用戶環境。在索引器定義中設定executionEnvironment參數，讓索引器始終在私有執行環境中執行。

IP 防火牆會阻擋多租戶環境，所以如果你有防火牆，請建立允許多租戶處理器連線的規則。

索引器的限制因環境而異：

工作量	最大持續時間	工作數上限	執行環境
私人處決	24小時	每個搜尋單位一個索引器工作¹。	索引不會在背景執行。相反地，搜尋服務會將所有索引工作與持續進行的查詢及物件管理操作（例如建立或更新索引）進行平衡。執行索引器時，如果索引卷很大，你應該預期會有一些查詢延遲。
多租戶	2小時 ²	不確定 ³	由於內容處理叢集為多租戶，系統會新增內容處理器以滿足需求。如果你在按需或排程執行中遇到延遲，通常是因為系統正在新增處理器，或是在等待新的處理器可用。

¹ 搜尋單元可以是分割區和副本的彈性組合，但索引工作不會綁定於其中一種。換句話說，如果你有 12 個單位，無論搜尋單位如何部署，都可以同時執行 12 個索引器工作。

² 若處理所有資料需超過兩小時，請啟用變更偵測，並排程索引器以 5 分鐘間隔運行，以便在因逾時停止時迅速恢復索引。更多策略請參見「索引大型資料集」。

³ 「不確定」的意思是限制不以工作數量來量化。某些工作負載，如技能集處理，可以平行執行，即使只有一個索引器，也可能產生許多工作。雖然環境不會施加限制，但你的搜尋服務索引器限制仍然適用。

不重置即可運行

執行索引器操作只會偵測並處理它需要的部分，以同步搜尋索引與底層資料來源的變更。累加式索引會先找出內部高水位線，以尋找最後更新的搜尋文件。此文件成為索引器執行資料來源中新文件與更新文件的起點。

變更偵測對於判斷資料來源中有哪些新內容或更新內容至關重要。索引器利用底層資料來源的變更偵測功能來判斷資料來源中有哪些新內容或更新內容。

Azure 儲存體內建了透過 LastModified 屬性進行變更偵測的功能。
其他資料來源，如 Azure SQL 或 Azure Cosmos DB，則需要先設定變更偵測，索引器才能讀取新資料列與更新資料列。

若底層內容不變，執行操作則無效。此時，索引器的執行歷史顯示 0\0 文件已處理中。

要重新處理所有文件，你需要重置索引器。

重置索引器

初始執行後，索引器會透過內部 高水位標記追蹤哪些搜尋文件被索引。該標記不會對外公開，但索引器內部知道它上次停止的位置。

若要重建全部或部分索引，請使用物件階層中遞減層級的重置 API：

重設索引子會清除高水位線，並對所有文件執行完整的重新建立索引。
重新同步索引器（預覽）能有效地部分重新索引所有文件。
重設文件索引（預覽）會重新索引特定文件或文件清單。
重置技能（預覽）會啟動特定技能的技能處理。

重置後，接著執行執行指令重新處理新舊文件。您無法透過重設並執行，移除在資料來源中沒有對應項目的孤立搜尋文件。若要刪除特定文件，請參見「在搜尋索引中刪除文件」或「文件-索引」。

註

桌子不能空著。如果你用 TRUNCATE TABLE 來清除資料列，重設索引器並執行索引器並不會移除對應的搜尋文件。若要移除孤立的搜尋文件，您必須使用刪除動作為其編製索引。

如何重置並執行索引器

重置會清除高水位標記。搜尋索引中的所有文件都會被標記為完全覆寫，不會進行內嵌更新或合併到現有內容。對於具有技能和擴充快取（預覽版）的索引器，重設索引也會隱式重設技能。

實際工作發生在你重置後執行 Run 指令時。

所有找到底層來源的新文件都會加入搜尋索引。
所有同時存在於資料來源與搜尋索引的文件，都會被覆蓋在搜尋索引中。
任何由技能組合創造的豐富內容都會被重建。如果啟用了增強緩存，該緩存將被刷新。

如前所述，重置是一種被動操作：您必須接著執行「Run」請求來重建索引。

重設/執行作業適用於搜尋索引或知識存放區、特定文件或投影，以及在重設明確或隱含包含技能時，適用於快取的擴充。

重置也適用於建立與更新操作。此作業不會觸發刪除或清除搜尋索引中的孤立文件。欲了解更多刪除文件的資訊，請參閱文件 - 索引。

重置操作無法撤銷。

前往 Azure 入口網站中的搜尋服務。
在概覽頁面，選擇 索引器 標籤。
選擇索引器。
選擇重置指令，然後選擇「是」來確認該動作。
重新整理頁面以顯示狀態。您可以選擇該項目查看其詳細資訊。
選擇執行以開始索引器處理，或等待下一次排程執行。

以下範例說明如何使用 Reset Indexer 和 Run Indexer REST 呼叫。使用 「取得索引器狀態 」來檢查結果。

這些呼叫不需要任何參數或屬性。

POST /indexers/[indexer name]/reset?api-version=[api-version]

POST /indexers/[indexer name]/run?api-version=[api-version]

GET /indexers/[indexer name]/status?api-version=[api-version]

以下範例（來自 azure-search-dotnet-samples/multiple-data-sources/）展示了如何在 Azure .NET SDK 中使用 ResetIndexers 和 RunIndexers 方法。

// Reset the indexer if it already exists
try
{
    await indexerClient.GetIndexerAsync(blobIndexer.Name);
    //Rest the indexer if it exsits.
    await indexerClient.ResetIndexerAsync(blobIndexer.Name);
}
catch (RequestFailedException ex) when (ex.Status == 404) { }

await indexerClient.CreateOrUpdateIndexerAsync(blobIndexer);

// Run indexer
Console.WriteLine("Running Blob Storage indexer...\n");

try
{
    await indexerClient.RunIndexerAsync(blobIndexer.Name);
}
catch (RequestFailedException ex) when (ex.Status == 429)
{
    Console.WriteLine("Failed to run indexer: {0}", ex.Message);
}

如何重置技能（預覽）

重置技能請求在下一次索引器執行時，選擇性地處理一項或多項技能。對於具有技能的索引器，您可以重設個別技能，以強制只重新處理該技能，以及任何依賴其輸出的下游技能。如果你啟用了擴充快取，該請求也會重新整理該快取。

對於啟用快取的索引器，你可以明確請求處理索引器無法偵測的技能更新。例如，如果你做了外部修改，例如自訂技能的修訂，請使用這個 API 來重新執行該技能。此程序會利用快取中的可重複使用資料，以及根據更新後的技能產生的新內容，重新整理輸出結果，例如知識儲存或搜尋索引。

使用最新的預覽 API。

POST /skillsets/[skillset name]/resetskills?api-version=2026-08-01-preview
{
    "skillNames" : [
        "#1",
        "#5",
        "#6"
    ]
}

你可以指定個別技能，如前述範例所示，但如果這些技能需要輸出未列出的技能（#2 到 #4），程序會執行未列出的技能，除非快取能提供必要資訊。若要讓此條件成立，技能 #2 到 #4 的快取擴充不得相依於 #1 (列為要重設的技能)。

如果你沒有指定任何技能，程序會執行整個技能組，如果啟用快取，也會刷新快取。

記得後續使用 Run Indexer 來啟動實際處理。

如何重設文件（預覽）

索引器 - 重設文件（預覽）API 接受文件鍵列表，讓你能重新整理特定文件。如果你指定重置參數，它們只會決定哪些要處理，不管底層資料有沒有其他變動。舉例來說，如果自上次索引器執行以來新增或更新了 20 個 blob，但你只重置了一份文件，索引器就只處理那份文件。

以每份文件為單位，索引器會以資料來源的值與元資料刷新搜尋文件中的所有欄位。你無法挑選要刷新哪些欄位。

如果資料來源是 Azure Data Lake Storage （ADLS） Gen2，且 blobs 與權限元資料相關聯，索引器會在底層資料權限變動時，將這些權限重新匯入搜尋索引中。欲了解更多資訊，請參閱使用 ADLS Gen2 索引器重新索引 ACL 與 RBAC 範圍。

如果你透過技能組豐富文件且有快取資料，索引器會只針對指定文件調用技能組，並更新重處理文件的快取。

當你第一次測試這個 API 時，以下的 API 可以幫助你驗證並測試這些行為。使用最新的預覽 API。

呼叫具有預覽 API 版本的索引器 - 獲取狀態以檢查重置狀態和執行狀態。您可以在狀態回應的最後找到關於重置請求的資訊。
呼叫索引器 - 以預覽 API 版本重設文件，指定要處理哪些文件。
```
POST https://[service name].search.windows.net/indexers/[indexer name]/resetdocs?api-version=2026-08-01-preview
{
    "documentKeys" : [
        "1001",
        "4452"
    ]
}
```
- API 接受兩種類型的文件識別碼作為輸入：用於唯一識別搜尋索引文件的文件鍵，以及唯一識別資料來源文件識別碼的資料來源文件識別碼。主體應包含文件鍵項 清單或 索引器在資料來源中尋找的資料來源文件識別碼清單。叫用 API 會將要重設的文件索引鍵或資料來源文件識別碼新增至索引子中繼資料。在下一次排程或按需執行索引器時，索引器只會處理重置文件。
- 如果你使用文件鍵來重置文件，且你的文件鍵在索引器欄位映射中被參考，索引器則會利用欄位映射來定位底層資料來源中的適當欄位。
- 你在請求中提供的文件鍵是來自搜尋索引的值，這可能與資料來源中對應的欄位不同。如果你不確定鍵值，可以發送查詢回傳該值。你可以用 select 來只回傳文件鍵欄位。
- 對於會被索引器剖析成多個搜尋文件的 blob（當 parsingMode 設為 jsonLines 或 jsonArrays，或 delimitedText 時），索引器會產生文件索引鍵，而你可能不知道該索引鍵。在本情境中，查詢文件索引鍵以傳回正確值。
- 如果你想讓索引器停止嘗試處理重設文件，請設定 "documentKeys" 或 "datasourceDocumentIds" 為空清單 []。此舉導致索引器恢復基於高水位點的常規索引。無效的文件鍵或不存在的文件鍵會被忽略。
呼叫 Run Indexer （任何 API 版本）來處理你指定的文件。索引器僅索引特定文件。
再呼叫一次 Run Indexer ，從最後一個高水位點開始處理。
請致電搜尋文件查詢更新值，若不確定值，也請回傳文件鍵。如果你想限制回應中出現的欄位，可以使用。"select": "<field names>"

覆寫文件鍵列表

如果你多次用不同鍵呼叫 Reset Documents API，新的鍵會被加入被重置的文件鍵清單。如果你呼叫 API 並將 overwrite 參數設為 true，目前的清單會被新的清單取代：

POST https://[service name].search.windows.net/indexers/[indexer name]/resetdocs?api-version=2026-08-01-preview
{
    "documentKeys" : [
        "200",
        "630"
    ],
    "overwrite": true
}

如何重新同步索引器（預覽）

Resync Indexers 是一個預覽版 REST API，能對所有文件進行部分重新索引。當目標索引中所有文件的特定欄位與資料來源資料一致時，索引器即被視為與其資料來源同步。通常，索引器會在成功完成初始執行後實現同步。如果你從資料來源刪除文件，索引器依此定義仍保持同步。然而，在下一次索引器執行時，若啟用刪除追蹤，目標索引中對應的文件會被移除。

如果你修改資料來源中的文件，索引器就會變得不同步。一般來說，變更追蹤機制會在下一次執行時重新同步索引器。例如，在 Azure 儲存體中，修改 Blob 會更新其上次修改時間，因此索引器可在下一次執行時重新為該 Blob 建立索引，因為更新後的時間會超過前一次執行所設定的高水位標記。

相較之下，對於某些資料來源（例如 ADLS Gen2），修改 Blob 的存取控制清單（ACL）不會改變其上次修改時間，因此如果要擷取 ACL，變更追蹤就無效。因此，修改後的 Blob 不會在後續執行中重新編製索引，因為只會處理在上一個高水位標記之後修改的文件。

雖然使用「重設」或「重設文件」可以解決這個問題，但「重設」對於大型資料集來說既耗時又效率低，而「重設文件」則需要識別你想更新的 blob 的文件鍵。

Resync 索引器提供了一個高效且便利的替代方案。你只要把索引器設為重新同步模式，然後透過呼叫重新同步索引器 API 來指定要重新同步的內容即可。在下一次執行中，索引器只會檢查來源中相關資料部分，並避免與指定資料無關的不必要處理。它也會查詢目標索引中現有的文件，並只更新顯示資料來源與目標索引之間差異的文件。重新同步執行後，索引器會同步並回復到後續執行時的常規索引器運行模式。

如何重新同步並執行索引器

使用預覽版 API 版本呼叫 Indexers - Resync，以指定要重新同步處理的內容。
```
POST https://[service name].search.windows.net/indexers/[indexer name]/resync?api-version=2026-08-01-preview
{
    "options" : [
        "permissions"
    ]
}
```
- options欄位是必填的。目前唯一支援的選項是 permissions。也就是說，只有目標索引中的權限篩選欄位會被更新。
呼叫執行索引器（任何 API 版本）來重新同步索引器。
再呼叫一次 Run Indexer ，從最後一個高水位點開始處理。

檢查重置狀態「currentState」

要檢查重置狀態並查看哪些文件鍵正排隊處理，請依照以下步驟操作：

透過預覽 API 呼叫「取得索引器狀態」。

預覽 API 會回傳位於回應末尾的 currentState 區段。

"currentState": {
    "mode": "indexingResetDocs",
    "allDocsInitialTrackingState": "{\"LastFullEnumerationStartTime\":\"2021-02-06T19:02:07.0323764+00:00\",\"LastAttemptedEnumerationStartTime\":\"2021-02-06T19:02:07.0323764+00:00\",\"NameHighWaterMark\":null}",
    "allDocsFinalTrackingState": "{\"LastFullEnumerationStartTime\":\"2021-02-06T19:02:07.0323764+00:00\",\"LastAttemptedEnumerationStartTime\":\"2021-02-06T19:02:07.0323764+00:00\",\"NameHighWaterMark\":null}",
    "resetDocsInitialTrackingState": null,
    "resetDocsFinalTrackingState": null,
    "resyncInitialTrackingState": null,
    "resyncFinalTrackingState": null,
    "resetDocumentKeys": [
        "200",
        "630"
    ]
}

檢查「模式」：

對於重置技能，請將「模式」設為indexingAllDocs，因為就 AI 擴充所填入的各欄位而言，可能所有文件都會受到影響。

對於重新同步索引器，請將「mode」設為 indexingResync。索引器會檢查所有文件，並專注於資料來源中感興趣的資料及目標索引中感興趣的欄位。

對於重設文件，請將「mode」設為 indexingResetDocs。索引器會維持此狀態，直到處理完 reset documents 呼叫中提供的所有文件索引鍵。在此期間，當此作業進行時，不會執行其他索引器工作。要找到文件鍵列表中的所有文件，需要破解每份文件以定位並匹配該鍵。如果資料集很大，這個過程可能會花上一段時間。如果 blob 容器中包含數百個 blob，而你想要重設的文件位於最後面，索引子必須先檢查完其他所有 blob，才會找到相符的 blob。
索引器重新處理文件後，再次執行「取得索引器狀態」。索引器會回到該 indexingAllDocs 模式，並在下一次執行時處理任何新增或更新的文件。

請檢查 S3 HD 和無伺服器搜尋服務的索引器執行時配額

本節適用於標準 3 高密度（S3 HD）及無伺服器搜尋服務。關於彙總配額行為與規劃指引，請參閱無伺服器與 S3 HD 上的索引器執行（預覽版）。

每次索引器運行時間上限為兩小時。另外，所有索引器在每個 24 小時 UTC 時間窗口內，共享每項服務的累積運行時間 24 小時。

為了協助您監控索引器的運行時間相對於 24 小時的視窗，Get Service Statistics 和 Get Indexer Status 現在在回應中提供更多資訊。

追蹤累積運行時間配額

追蹤搜尋服務的累積索引器執行時使用量，並判斷目前 24 小時內剩餘的執行時配額。

向搜尋服務端點發送 GET 請求。如需協助設定 REST 用戶端及取得存取權杖，請參閱「連接至搜尋服務」。

GET {{search-endpoint}}/servicestats?api-version=2026-08-01-preview
  Content-Type: application/json
  Authorization: Bearer {{accessToken}}

回應包含 indexersRuntime 顯示視窗開始與結束時間、所有索引器累積使用的秒數，以及服務剩餘秒數的屬性。

追蹤索引器執行時配額

對單一索引器回傳相同資訊。

GET {{search-endpoint}}/indexers/hotels-sample-indexer/search.status?api-version=2026-08-01-preview
  Content-Type: application/json
  Authorization: Bearer {{accessToken}}

回應包含 runtime 顯示視窗開始與結束時間、索引器使用的秒數，以及服務中所有索引器的剩餘秒數的屬性。

下一步

重置 API 用於通知下一次索引器執行的範圍。若要實際進行處理，您需要叫用隨選索引子執行，或讓排程作業完成工作。該次執行完成後，索引器會恢復正常處理，不論是依排程或隨選處理。

在你重置並重執行索引工作後，你可以從搜尋服務中監控狀態，或透過資源記錄獲取詳細資訊。

意見反應

此頁面對您有幫助嗎？

Last updated on 2026-08-17