為 適用於 MySQL 的 Azure 資料庫 彈性伺服器（預覽版）中的資料建立索引

適用於 MySQL 的 Azure 資料庫 索引器（預覽版）會將 適用於 MySQL 的 Azure 資料庫 Flexible Server 的內容匯入 Azure AI 搜尋服務 索引。 索引子的輸入是單一資料表或檢視中的資料列。 輸出是一個包含各欄位可搜尋內容的搜尋索引。

本文補充建立索引子，並提供從適用於 MySQL 的 Azure 資料庫彈性伺服器編製索引的特定資訊。 它使用 REST API 展示所有索引器共有的三步驟工作流程：建立資料來源、建立索引、建立索引器。 資料擷取發生在你提交建立索引器請求時。

設定為包含高水位標記和虛刪除時，索引子會取得 MySQL 資料庫的所有變更、上傳和刪除。 它將這些變化反映在您的搜尋索引中。 資料擷取發生在你提交建立索引器請求時。

先決條件

• 請填寫 索引預覽註冊表單。 報名會自動通過。

• 適用於 MySQL 的 Azure 資料庫 彈性伺服器及示例資料。 資料必須存在於表格或檢視中。 需要一個主鍵。 如果您使用檢視，則該檢視必須有高水位標記資料行。

• 閱讀權限。 完整存取連接字串包含一個授權存取內容的金鑰，但如果你使用 Azure 角色，請確保搜尋服務託管身分識別在 MySQL 上擁有 Reader 權限。

• 一個 REST 客戶端 用來建立資料來源、索引和索引器。

  你也可以使用Azure SDK for .NET。 你不能用 Azure 入口網站來建立索引器，但一旦建立索引器和資料來源，你可以管理它們。

預覽限制

目前，如果所有資料列的日期或時間戳都一致，變更追蹤和刪除偵測就無法運作。 這個限制是已知會在預覽版更新中解決的問題。 在這個問題解決之前，不要在 MySQL 索引器中新增技能組。

預覽版不支援幾何類型和斑點。

如前所述，網站不支援建立索引器，但一旦 MySQL 索引器和資料來源存在，可以在 Azure 入口網站中管理。 例如，你可以編輯定義，並重設、執行或排程索引器。

定義資料來源

資料來源定義指定了索引資料、憑證及識別資料變更的政策。 資料來源被定義為獨立資源，因此可由多個索引器使用。

建立或更新資料來源用於指定定義。 建立資料來源時，務必使用預覽版的 REST API。

{   
    "name" : "hotel-mysql-ds",
    "description" : "[Description of MySQL data source]",
    "type" : "mysql",
    "credentials" : { 
        "connectionString" : 
            "Server=[MySQLServerName].MySQL.database.azure.com; Port=3306; Database=[DatabaseName]; Uid=[UserName]; Pwd=[Password]; SslMode=Preferred;" 
    },
    "container" : { 
        "name" : "[TableName]" 
    },
    "dataChangeDetectionPolicy" : { 
        "@odata.type": "#Microsoft.Azure.Search.HighWaterMarkChangeDetectionPolicy",
        "highWaterMarkColumnName": "[HighWaterMarkColumn]"
    }
}

重點：

• 設定 type 為 "mysql" （必需）。

• 將 credentials 設為 ADO.NET 連接字串。 你可以在 Azure 入口網站的 MySQL Connection strings 頁面找到連線字串。

• 設定 container 成資料表名稱。

• 設定 dataChangeDetectionPolicy 資料是易失的，並且你希望索引器在後續執行中只接收新且更新的項目。

• 如果你想在來源項目被刪除時，從搜尋索引中移除搜尋文件，請設定 dataDeletionDetectionPolicy 。

建立索引

建立或更新索引 指定索引結構：

{
    "name" : "hotels-mysql-ix",
    "fields": [
        { "name": "ID", "type": "Edm.String", "key": true, "searchable": false },
        { "name": "HotelName", "type": "Edm.String", "searchable": true, "filterable": false },
        { "name": "Category", "type": "Edm.String", "searchable": false, "filterable": true, "sortable": true  },
        { "name": "City", "type": "Edm.String", "searchable": false, "filterable": true, "sortable": true },
        { "name": "Description", "type": "Edm.String", "searchable": false, "filterable": false, "sortable": false  }     
    ]
}

如果來源資料表中的主鍵與文件鍵（此處為「ID」）相符，索引器會將主鍵匯入為文件鍵。

映射資料類型

下表將 MySQL 資料庫對應至 Azure AI 搜尋服務 的對應版本。 更多資訊請參閱 支援資料型別（Azure AI 搜尋服務）。

設定並執行 MySQL 索引器

一旦索引和資料來源建立完成，你就可以開始建立索引器了。 索引器配置指定控制執行時行為的輸入、參數與屬性。

透過命名索引器並引用資料來源與目標索引，建立或更新它：

{
    "name" : "hotels-mysql-idxr",
    "dataSourceName" : "hotels-mysql-ds",
    "targetIndexName" : "hotels-mysql-ix",
    "disabled": null,
    "schedule": null,
    "parameters": {
        "batchSize": null,
        "maxFailedItems": null,
        "maxFailedItemsPerBatch": null,
        "base64EncodeKeys": null,
        "configuration": { }
        },
    "fieldMappings" : [ ],
    "encryptionKey": null
}

重點：

• 如果欄位名稱或類型有差異，或搜尋索引中需要多個來源欄位版本，請指定欄位對應。

• 索引器在建立時會自動執行。 你可以透過設定 disabled 為 true來阻止它執行。 要控制索引器的執行，請按 需求執行索引器 或 將其列入排程。

檢查索引器狀態

發送 Get Indexer Status 請求以監控索引器的執行：

GET https://myservice.search.windows.net/indexers/myindexer/status?api-version=2026-08-01-preview
  Content-Type: application/json  
  api-key: [admin key]

回應內容包括狀態及已處理項目數量。 它應該看起來像以下範例：

{
    "status":"running",
    "lastResult": {
        "status":"success",
        "errorMessage":null,
        "startTime":"2024-02-21T00:23:24.957Z",
        "endTime":"2024-02-21T00:36:47.752Z",
        "errors":[],
        "itemsProcessed":1599501,
        "itemsFailed":0,
        "initialTrackingState":null,
        "finalTrackingState":null
    },
    "executionHistory":
    [
        {
            "status":"success",
            "errorMessage":null,
            "startTime":"2024-02-21T00:23:24.957Z",
            "endTime":"2024-02-21T00:36:47.752Z",
            "errors":[],
            "itemsProcessed":1599501,
            "itemsFailed":0,
            "initialTrackingState":null,
            "finalTrackingState":null
        },
        ... earlier history items
    ]
}

執行歷史包含最多 50 次最近完成的執行，並依逆時間順序排序，使最新的執行先行。

索引新資料列和已變更的資料列

索引器一旦完全填滿搜尋索引，你可能會希望後續的索引器執行時，只針對資料庫中新增和變更的列進行增量索引。

要啟用增量索引，請在你的資料來源定義中設定該 dataChangeDetectionPolicy 屬性。 此特性告訴索引器您的資料使用了哪種變更追蹤機制。

對於適用於 MySQL 的 Azure 資料庫索引器，唯一支援的策略是 HighWaterMarkChangeDetectionPolicy。

索引器的變更偵測政策依賴於一個 高水印 欄位，該欄位能捕捉列版本，也就是列最後更新的日期和時間。 它通常是 DATE、DATETIME 或 TIMESTAMP 資料行，其細微性足以符合高水位標記資料行的需求。

在您的 MySQL 資料庫中，高水位標記欄位必須符合以下條件：

• 所有資料插入必須指定欄位的值。
• 所有對項目的更新也會改變該欄位的值。
• 此欄位的值會隨著每次插入或更新而增加。
• 包含以下 WHERE 子句與 ORDER BY 子句的查詢可以有效執行： WHERE [High Water Mark Column] > [Current High Water Mark Value] ORDER BY [High Water Mark Column]

以下範例展示了帶有變更偵測政策的資料 來源定義 ：

{
    "name" : "[Data source name]",
    "type" : "mysql",
    "credentials" : { "connectionString" : "[connection string]" },
    "container" : { "name" : "[table or view name]" },
    "dataChangeDetectionPolicy" : {
        "@odata.type" : "#Microsoft.Azure.Search.HighWaterMarkChangeDetectionPolicy",
        "highWaterMarkColumnName" : "[last_updated column name]"
    }
}

正在對已刪除的資料列進行索引

當資料表或檢視中刪除資料列時，通常你也想從搜尋索引中刪除這些資料列。 然而，如果這些列被物理地從表格中移除，索引器就無法推斷出已不存在的紀錄是否存在。 解決方法是使用 軟刪除 技術，邏輯性地刪除列，但不將它們從資料表中移除。 在你的表格中新增一欄，或檢視並用該欄標記已刪除的列。

給定一個提供刪除狀態的欄位，索引器可以設定移除任何刪除狀態設為 true的搜尋文件。 支援此行為的設定屬性是資料刪除偵測策略，資料 來源定義 中規定如下：

{
    …,
    "dataDeletionDetectionPolicy" : {
        "@odata.type" : "#Microsoft.Azure.Search.SoftDeleteColumnDeletionDetectionPolicy",
        "softDeleteColumnName" : "[a column name]",
        "softDeleteMarkerValue" : "[the value that indicates that a row is deleted]"
    }
}

softDeleteMarkerValue一定是一串線。 例如，如果你有一欄整數，刪除的列以 1 標記，請使用 "1"。 如果您有 BIT 資料行，且已刪除的資料列以布林值 true 標記，請使用字串常值 True 或 true (不區分大小寫)。

下一步

你現在可以 執行索引器、 監控狀態，或 排程索引器執行。 以下文章適用於從 Azure MySQL 擷取內容的索引器：

• 索引大型資料集
• 索引器存取受Azure網路安全功能保護的內容