提示，以提升 Azure AI 搜尋的效能
本文是提升查詢和編製索引效能的秘訣和最佳做法集合。 瞭解哪些因素最有可能影響搜尋效能，可協助您避免效率低下，並充分利用您的搜尋服務。 一些主要因素包括：
- 索引組合（架構和大小）
- 查詢設計
- 服務容量（層和複本和分割區數目）
注意
正在尋找大量索引編製策略嗎？ 請參閱 在 Azure AI 搜尋中編制大型數據集的索引。
索引大小和架構
查詢在較小的索引上執行得更快。 這部分是具有較少字段可掃描的功能，但也是因為系統如何快取未來查詢的內容。 第一次查詢之後，某些內容會保留在記憶體中，其搜尋效率更高。 因為索引大小通常會隨著時間成長，因此最佳做法是定期重新瀏覽架構和檔索引組合，以尋找減少內容的機會。 不過，如果索引的大小正確，唯一可以進行的校正就是增加容量：新增 複 本或升級服務層級。 「提示：升級至標準 S2 層」一節討論相應增加與相應放大決策。
架構複雜度也可能對索引編製和查詢效能造成負面影響。 過多的欄位屬性會以限制和處理需求為基礎而建置。 複雜類型 需要較長的時間才能編製索引和查詢。 接下來的幾節會探索每個條件。
提示：在欄位屬性中是選擇性的
系統管理員和開發人員在建立搜尋索引時所犯的常見錯誤是選取欄位的所有可用屬性，而不是只選取所需的屬性。 例如，如果欄位不需要全文搜索，請在設定可搜尋的屬性時略過該欄位。
對篩選、Facet 和排序的支援可能會有四倍的儲存需求。 如果您新增建議工具，記憶體需求會增加更多。 如需屬性對記憶體影響圖例，請參閱 屬性和索引大小。
摘要說明，過度歸屬的影響包括：
由於處理欄位中內容所需的額外工作，編製索引效能降低，然後將它儲存在搜尋反向索引內（只在包含可搜尋內容的欄位上設定「可搜尋」屬性）。
建立每個查詢必須涵蓋的較大介面。 標示為可搜尋的所有欄位都會在全文搜索中掃描。
由於額外的記憶體，會增加營運成本。 篩選和排序需要額外的空間來儲存原始的（非分析）字串。 避免在不需要篩選的欄位上設定可篩選或可排序。
在許多情況下，過度屬性會限制欄位的功能。 例如，如果欄位可多面向、可篩選且可搜尋，您就只能在字段中儲存 16 KB 的文字，而可搜尋的欄位最多可以容納 16 MB 的文字。
注意
只應避免不必要的歸因。 篩選和 Facet 通常對於搜尋體驗至關重要，而且在使用篩選的情況下，您通常需要排序，以便排序結果（篩選本身會傳回未排序的集合中）。
提示：考慮複雜類型的替代方案
當數據具有複雜的巢狀結構時，複雜數據類型很有用，例如 JSON 檔中找到的父子元素。 複雜類型的缺點是相較於非複雜數據類型，額外的記憶體需求和編製內容索引所需的額外資源。
在某些情況下，您可以將複雜的數據結構對應至較簡單的欄位類型，例如 Collection，以避免這些取捨。 或者，您可以選擇將欄位階層扁平化為個別根層級欄位。
查詢設計
查詢組合和複雜度是效能最重要的因素之一，而查詢優化可以大幅改善效能。 設計查詢時，請考慮下列幾點：
可搜尋的欄位數目。 每個額外的可搜尋欄位都會讓搜尋服務有更多工作。 您可以使用 「searchFields」 參數來限制在查詢時間搜尋的欄位。 最好只指定您關注的欄位，以改善效能。
傳回的數據量。 擷取大量內容可能會讓查詢變慢。 建構查詢時，只傳回您呈現結果頁面所需的欄位，然後在使用者選取相符項之後，使用查閱 API 擷取其餘欄位。
使用部分字詞搜尋。部分字詞搜尋，例如前置詞搜尋、模糊搜尋和正則表達式搜尋，比一般關鍵詞搜尋更耗費計算成本，因為它們需要完整索引掃描來產生結果。
Facet 數目。 將 Facet 新增至查詢需要彙總每個查詢。 對 Facet 要求越高的「計數」，服務也需要執行更多工作。 一般而言，請只新增您打算在應用程式中呈現的 Facet，除非必要，避免對 Facet 要求太高計數。
高略過值。 將
$skip參數的值設定太高 (例如數千個) 會增加搜尋延遲，因為引擎需要針對每個要求來擷取和排名更大量文件。 基於效能理由，最好避免太高的$skip值，並改用其他技術 (例如篩選) 來擷取大量文件。避免高基數欄位。 高基數位段是指可多面向或可篩選的欄位，其具有大量唯一值，因此，計算結果時會耗用大量資源。 例如，將 [產品標識符] 或 [描述] 字段設定為可Facet且可篩選的會算作高基數，因為從檔到檔的大部分值都是唯一的。
提示：改用搜尋函式多載篩選準則
當查詢使用越來越 複雜的篩選準則時，搜尋查詢的效能將會降低。 請考慮下列範例，示範如何使用篩選來根據使用者身分識別來修剪結果：
$filter= userid eq 123 or userid eq 234 or userid eq 345 or userid eq 456 or userid eq 567
在此情況下，篩選表達式可用來檢查每個檔中的單一字段是否等於使用者身分識別的許多可能值之一。 您最有可能在實 作安全性修剪 的應用程式中找到此模式（針對代表發出查詢之使用者之主體標識元清單檢查包含一或多個主體標識符的欄位）。
執行包含大量值的篩選更有效率的方式是使用 search.in 函式，如下列範例所示：
search.in(userid, '123,234,345,456,567', ',')
提示：為緩慢的個別查詢新增數據分割
一般而言，當查詢效能變慢時，新增更多複本會經常解決問題。 但如果問題是單一查詢需要太長的時間才能完成，該怎麼辦？ 在此案例中，新增複本並無濟於事，但可能會有更多分割區。 分割區會將數據分割到額外的運算資源。 兩個分割區將數據分割成一半，第三個分割區會將它分割成第三個分割區，依此類推。
新增數據分割的一個正面副作用是，由於平行運算，查詢有時會執行得更快。 我們已注意到低選擇性查詢的平行處理，例如符合許多文件的查詢，或提供大量檔計數的 Facet。 由於需要大量計算才能評分文件的相關性，或計算檔數目，因此新增額外的分割區可協助查詢更快完成。
若要新增分割區，請使用 Azure 入口網站、PowerShell、Azure CLI 或管理 SDK。
服務容量
當查詢花費太長或服務開始卸除要求時，服務就會過度負擔。 如果發生這種情況，您可以藉由升級服務或新增容量來解決問題。
搜尋服務的階層和複本/分割區的數目也會對效能產生很大影響。 每個漸進式較高層都提供更快的CPU和更多記憶體，這兩者對效能都有正面的影響。
提示：建立新的高容量搜尋服務
[在支持區域中建立的基本和標準服務]（在 2024 年 4 月 3 日之後支援的區域 ，每個分割區的記憶體比舊版服務多。 升級至較高層級和較高的計費費率之前，請重新瀏覽 階層服務限制 ，以查看較新服務上的同一層是否提供必要的記憶體。
提示：升級至標準 S2 層
標準 S1 搜尋層通常是客戶開始的地方。 S1 服務的常見模式是索引會隨著時間成長，這需要更多數據分割。 更多分割區會導致響應時間變慢，因此會新增更多複本來處理查詢負載。 如您所想像，執行S1服務的成本現在已進展到超過初始設定的層級。
在這個階段，要詢問的一個重要問題是，移至較高層級是有説明的，而不是逐漸增加目前服務的數據分割或複本數目。
請考慮下列拓撲作為服務範例，此服務已採用增加的容量層級：
- 標準 S1 層
- 索引大小：190 GB
- 資料分割計數：8（在 S1 上，分割區大小為每個分割區 25 GB）
- 復本計數：2
- 搜尋單位總數： 16 （8 個分割區 x 2 個複本）
- 假設零售價格：~4,000美元/月（假設 250 美元 x 16 個搜尋單位）
假設服務管理員仍然看到較高的延遲率，並考慮新增另一個複本。 這會將復本計數從 2 變更為 3，因此將搜尋單位計數變更為 24，且產生的價格為 $6,000 美元/月。
不過，如果系統管理員選擇移至標準 S2 層，拓撲看起來會像這樣：
- 標準 S2 層
- 索引大小：190 GB
- 資料分割計數：2（在 S2 上，分割區大小為每個分割區 100 GB）
- 復本計數：2
- 搜尋單位總數：4（2 個分割區 x 2 個複本）
- 假設零售價格：~4,000美元/月（1,000美元 x 4 個搜尋單位）
如此假設案例所說明，您可以在較低層上設定，這會產生類似的成本，就像您一開始選擇較高層一樣。 不過，較高層隨附進階記憶體，讓編製索引更快。 較高層也有更多的計算能力，以及額外的記憶體。 針對相同的成本，您可以擁有更強大的基礎結構來支援相同的索引。
新增記憶體的一個重要優點是可以快取更多索引，進而降低搜尋延遲，以及每秒更多的查詢數目。 有了這個額外的能力，系統管理員甚至不需要增加複本計數，而且可能會支付低於留在 S1 服務的費用。
提示：考慮正則表達式查詢的替代方案
正則表達式查詢 或 regex 可能特別昂貴。 雖然它們對於進階搜尋非常有用，但執行可能需要大量的處理能力，特別是當正則表達式很複雜，或是您正在搜尋大量數據時。 所有這些因素都會導致高搜尋延遲。 作為緩和措施，請嘗試簡化正則表達式，或將複雜查詢細分為更小、更容易管理的查詢。
下一步
請檢閱這些與服務效能相關的其他文章：