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

在 Azure AI 搜尋服務中，有數種方式可以執行索引子：

在建立索引器時立即執行。除非您以「已停用」狀態建立索引器，否則這是預設值。
依排程執行 (部分內容可能是機器或 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 防火牆會封鎖多租用戶環境，因此如果您有防火牆，請建立允許多租用戶處理器連線的規則。

索引子限制會因環境而有所不同：

Workload	最長持續時間	最大作業數	執行環境
私下執行	24 小時	每個搜尋單位對應一個索引作業¹。	索引編製作業不會在背景中執行。相反地，搜尋服務會針對進行中的查詢和物件管理動作（例如建立或更新索引）平衡所有編製索引作業。在執行索引器時，如果索引量很大，您應該會看到一些查詢延遲。
Multitenant	2 小時 ²	不確定 ³	由於內容處理叢集是多租使用者，因此會新增內容處理器以符合需求。如果您在隨需或排程的執行遇到延遲，原因可能是系統正在增加處理器或正在等候有處理器可供使用。

¹ 搜尋單位可以是分割區和複本的彈性組合，但索引子作業不會繫結至其中一項。換句話說，如果您有 12 個單位，則不論搜尋單位的部署方式為何，都可以在私人執行中同時執行 12 個索引子作業。

² 如果需要超過兩個小時來處理所有數據，請啟用變更偵測並排程索引器以 5 分鐘的間隔執行，以在因逾時而停止時快速繼續編製索引。如需更多策略，請參閱編製大型數據集的索引。

³ 「不確定」表示限制不是以作業數目來計算。部分運行負載（例如技能集處理）可以平行執行，這可能會導致產生許多作業，即使只有一個索引器參與。雖然環境不會增加限制，但搜尋服務的索引子限制仍適用。

執行但不重設

執行索引器作業只會偵測並處理同步處理搜尋索引與基礎數據源變更所需的專案。累加式索引編製首先會找到內部高水位線以尋找最後更新的搜尋文件，以作為對資料來源中的新文件和更新文件執行索引子的起點。

變更偵測對於判斷資料來源中的新內容或更新內容很重要。索引子會使用基礎資料來源的變更偵測功能來判斷資料來源中的新增或更新內容。

Azure 儲存體透過其 LastModified 屬性內建了變更偵測功能。
其他資料來源 (例如 Azure SQL 或 Azure Cosmos DB) 則必須先針對變更偵測進行設定，然後索引子才能讀取新的和更新的資料列。

如果基礎內容未變更，則執行作業不會產生影響。在此情況下，索引器執行歷程會顯示 0\0 文件的處理狀況。

您必須重設索引器，如下一節所述，以完整重新處理。

重設索引子

在初次執行後，索引子會追蹤有哪些搜尋文件已透過內部「高水位線」來編製索引。此標記永遠不會公開，但索引子會在內部掌握其上次停止的位置。

如果您需要重建全部或部分的索引，請使用物件階層中的遞減層級可用的重設 API：

重設索引子 (部分內容可能是機器或 AI 翻譯) 會清除高水位線，並完整地重新編製所有文件的索引
重新同步索引子 (預覽) 會執行所有文件的有效部分重新編製索引
重設文件 (預覽) 會重新編製特定文件或文件清單的索引
重設技能 (預覽) (部分內容可能是機器或 AI 翻譯) 會針對特定技能叫用技能處理

在重設之後，請遵循 Run 命令來重新處理新文件和現有文件。資料來源中沒有對應項目的孤立搜尋文件無法透過重設/執行來移除。如果您需要刪除特定文件，請參閱在搜尋索引中刪除文件或文件 - 索引。

Note

數據表不能是空的。如果您使用 TRUNCATE TABLE 清除資料列，索引器重設並重新執行將不會移除對應的搜尋檔。若要移除孤立的搜尋文件，您必須使用刪除動作編製索引。

如何重設和執行索引子

進行重設會清除高水位線。搜尋索引中的所有文件都會標示為完整覆寫，而不會內嵌更新或合併至現有內容。如果索引子有技能和擴充快取 (部分內容可能是機器或 AI 翻譯)，則重設索引也會隱含地重設該技能。

當您使用 Run 命令遵循重設時，就會發生實際的工作：

找到基礎來源的所有新文件都會新增至搜尋索引。
存在於數據源和搜尋索引中的所有文件都會在搜尋索引中覆寫。
會重建透過技能所建立的任何擴充內容。如果已啟用擴充快取，則會重新整理擴充快取。

如先前所述，重設是被動作業：您必須遵循執行要求來重建索引。

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

重設也適用於建立和更新作業。其不會觸發搜尋索引中孤立文件的刪除或清除。如需刪除文件的詳細資訊，請參閱文件 - 索引。

重設索引子之後，就無法復原此動作。

登入 Azure 入口網站並開啟搜尋服務頁面。
在 [概觀] 頁面上，選取 [索引器] 索引頁籤。
選擇索引器。
選取 [重設] 命令，然後選取 [是] 以確認此動作。
重新整理頁面以顯示狀態。您可以選取項目來檢視其詳細資料。
選取 [執行] 以啟動索引子處理，或等候所排程的下一次執行。

下列範例說明重設索引子和執行索引子 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);
}

如何重設技能 (預覽)

重設技能要求會在下一個索引子執行時選擇性地處理一或多個技能。對於具有技能集的索引器，您可以重設個別技能，以強制重新處理該技能，以及相依於其輸出的任何下游技能。如果您啟用擴充快取 (部分內容可能是機器或 AI 翻譯)，擴充快取也會重新整理。

對於已啟用快取的索引子，您可以明確地要求處理那些索引子無法偵測到的技能更新。例如，如果您進行外部變更，例如對自訂技能的修訂，則可以使用此 API 重新執行技能。輸出（例如知識存放區或搜尋索引）會根據更新的技能，使用快取中的可重複使用資料和新內容進行更新。

我們建議使用最新的預覽 API。

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

您可以如上述範例所示來指定個別技能，但如果其中有任何技能需要來自未列出技能的輸出 (#2 到 #4)，則除非快取可以提供必要資訊，否則未列出的技能將會執行。為了讓這一點成立，技能 #2 到技能 #4 的快取擴充不得相依於技能 #1 (已列入重設清單)。

如果未指定任何技能，則會執行整個技能集，而且如果啟用快取，快取也會重新整理。

請記得後續執行執行索引器，以觸發實際處理。

如何重設文件 (預覽)

索引器 - 重設文件（預覽）可接受文件鍵清單，讓您可以刷新特定文件。如果指定重設參數，則重設參數會變成決定受處理項目的唯一因素 (不論基礎資料中的其他變更為何)。例如，如果在上次執行索引子之後新增或更新了 20 個 Blob，但您只重設一份文件，則系統只會處理該文件。

該搜尋文件中的所有欄位都會按文件以資料來源的值和中繼資料加以重新整理。您無法挑選要重新整理的欄位。

如果數據源是 Azure Data Lake Storage （ADLS） Gen2，而且 Blob 與許可權元數據相關聯，則如果基礎數據中的許可權變更，這些許可權也會重新內嵌在搜尋索引中。如需詳細資訊，請參閱使用ADLS Gen2索引器重新編製 ACL 和 RBAC 範圍索引。

如果文件透過技能集加以擴充並已快取資料，則只會針對指定文件叫用技能集，並針對已重新處理的文件更新快取。

當您第一次測試此 API 時，下列 API 可協助您驗證及測試行為。我們建議最新的預覽版 API。

使用預覽 API 版本呼叫索引器 - 取得狀態，以檢查重設狀態和執行狀態。您可以在狀態回應結束時找到重設要求的相關資訊。
使用預覽 API 版本呼叫索引器 - 重設文件，以指定要處理的文件。
```
POST https://[service name].search.windows.net/indexers/[indexer name]/resetdocs?api-version=2025-11-01-preview
{
    "documentKeys" : [
        "1001",
        "4452"
    ]
}
```
- API 接受兩種類型的文件識別碼作為輸入：唯一識別搜尋索引中文件的文件索引鍵，以及唯一識別資料來源中文件的資料來源文件識別碼。正文應該包含文件鍵清單或索引器在資料來源中尋找的文件識別碼清單。叫用 API 會將要重設的文件索引鍵或資料來源文件識別碼新增至索引子中繼資料。在索引子下一次預定執行或隨需執行時，索引子只會處理已重置的文件。
- 如果您使用文件索引鍵來重設文件，且在索引子欄位對應中參考文件索引鍵，則索引子會使用欄位對應在基礎資料來源中尋找適當的欄位。
- 要求中提供的文件索引鍵是來自搜尋索引的值，這與資料來源中的對應欄位不同。如果您不確定索引鍵值，請傳送查詢以傳回值。您可以使用 select 只傳回文件索引鍵欄位。
- 針對剖析成多個搜尋文件的 Blob (其中 parsingMode 設定為 jsonLines 或 jsonArrays (部分內容可能是機器或 AI 翻譯) 或 delimitedText (部分內容可能是機器或 AI 翻譯))，索引子會產生文件索引鍵，但這些對您來說可能是未知的。在此情況下，文件索引鍵的查詢會傳回正確的值。
- 如果您想要索引子停止嘗試處理重設檔，您可以將 “documentKeys” 或 “datasourceDocumentIds” 設定為空白清單 “[]”。這會導致索引器根據高水位標記重新開始進行常規索引。系統會忽略無效的文件金鑰或不存在的文件金鑰。
呼叫執行索引子 (任何 API 版本) 來處理您指定的文件。只有這些特定文件會編製索引。
第二次呼叫 Run 索引子 (部分內容可能是機器或 AI 翻譯)，以從上一個高水位線開始處理。
呼叫搜尋文件來檢查更新的值，如果您不確定值，也可傳回文件索引鍵。如果您想要限制回應中出現的欄位，請使用 "select": "<field names>"。

覆寫文件索引鍵清單

使用不同索引鍵多次呼叫重設文件 API，會將新的索引鍵附加至文件索引鍵重設清單。呼叫 overwrite 參數設定為 true 的 API 將會以新的清單覆寫目前的清單：

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

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

重新同步索引子 (部分機器翻譯) 是預覽版 REST API，可對所有文件執行部分重新索引。當目標索引中所有檔的特定欄位與數據源中的數據一致時，索引器會被視為與其數據源同步處理。一般而言，索引器會在初始執行成功之後達到同步處理。如果從數據來源中刪除檔，索引器會根據此定義保持同步處理。不過，在下一個索引器執行期間，如果啟用刪除追蹤，將會移除目標索引中的對應檔。

如果在數據源中修改檔，索引器就會變成未同步處理。一般而言，變更追蹤機制會在下次執行期間重新同步索引器。例如，在 Azure 儲存體中，修改 Blob 會更新其上次修改的時間，讓它在後續的索引子執行中重新編製索引，因為更新的時間超過上一次執行所設定的高水位標記。

相反地，對於 ADLS Gen2 等特定資料來源，更改 Blob 的存取控制清單 (ACL) 不會變更其上次修改時間，如果要內嵌 ACL，則轉譯變更追蹤無效。因此，修改過的 Blob 不會在後續執行中重新編製索引，因為只會處理在最後一個高水位標記之後修改的文件。

雖然使用「重設」或「重設檔」可以解決此問題，但「重設」對於大型數據集而言可能非常耗時且效率不佳，而「重設檔」需要識別要更新之 Blob 的文件密鑰。

重新同步索引器提供有效率且方便的替代方案。使用者只要將索引器置於重新同步模式，並藉由呼叫重新同步索引器 API 來指定要重新同步處理的內容。在下一次執行中，索引器只會檢查來源中相關部分的數據，並避免任何與指定數據無關的不必要處理。它也會查詢目標索引中的現有檔，並只更新顯示數據源與目標索引之間不一致的檔。重新同步執行之後，索引器將會同步處理，並還原為後續執行的一般索引器執行模式。

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

呼叫索引器 - Resync，使用預覽 API 版本來指定要重新同步的內容。
```
POST https://[service name].search.windows.net/indexers/[indexer name]/resync?api-version=2025-11-01-preview
{
    "options" : [
        "permissions"
    ]
}
```
- options 是必填欄位。目前唯一支援的選項是 permissions。也就是說，只會更新目標索引中的許可權篩選欄位。
呼叫執行索引器（任何 API 版本）以重新同步處理索引器。
第二次呼叫 Run 索引子 (部分內容可能是機器或 AI 翻譯)，以從上一個高水位線開始處理。

檢查重設狀態「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"
    ]
}

檢查「mode」：

針對重設技能，「mode」應該設定為 indexingAllDocs (因為所有文件可能都會受到影響，就透過 AI 擴充所填入的欄位而言)。

針對重新同步索引器，「模式」應設定為 indexingResync。索引器會檢查所有檔，並著重於數據源中感興趣的數據，以及目標索引中感興趣的欄位。

針對重設文件，「mode」應該設定為 indexingResetDocs。索引子會保持此狀態，直到重設文件呼叫中所提供的文件索引鍵均完成處理為止，在此期間，不會在作業進行時再執行其他任何索引子作業。在文件鍵列表中尋找所有文件時，需要解析每個文件以找到並匹配鍵，如果資料集很大，這可能會耗費一些時間。如果 Blob 容器包含數百個 Blob，而您想要重設的文件位於末端，則索引子在先檢查所有其他 Blob 之前，都不會找到相符的 Blob。
文件重新處理完之後，請再次執行「取得索引子狀態」。索引子會返回 indexingAllDocs 模式，並且會在下一次執行時處理任何新的或更新的文件。

檢查 S3 HD 搜尋服務的索引子執行時間配額

適用於標準 3 高密度 (S3 HD) 定價層的搜尋服務。

為了協助您監視索引子在 24 小時時限內的執行時間，取得服務統計資料 (部分機器翻譯) 和取得索引子狀態 (部分機器翻譯) 現在會在回應中傳回更多資訊。

追蹤累積執行時間配額

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

將 GET 要求傳送至搜尋服務資源提供者。如需如何設定 REST 用戶端和取得存取權杖的說明，請參閱連線到搜尋服務。

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

回應中會包含 indexersRuntime 屬性，顯示開始和結束時間、使用的秒數、剩餘秒數，以及過去 24 小時內的累積執行時間。

追蹤索引子執行時間配額

傳回單一索引子的相同資訊。

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

回應中會包含 runtime 屬性，顯示開始和結束時間、使用的秒數和剩餘秒數。

後續步驟

重設 API 可用來通知下一次索引子執行的範圍。針對實際處理，您必須叫用隨需索引子執行，或允許排程的作業完成工作。執行完成之後，索引子會回復為正常處理 (無論是排程處理還是隨需處理)。

重設並重新執行索引子作業之後，您可以從搜尋服務監視狀態，或透過資源記錄取得詳細資訊。

監視搜尋索引子狀態
收集和分析記錄資料
排程索引子 (部分內容可能是機器或 AI 翻譯)

意見反應

此頁面對您有幫助嗎？

Last updated on 2025-10-03