Azure 搜尋中的服務限制Service limits in Azure Search

儲存體、工作負載的最大限制, 以及索引、檔和其他物件的數量上限, 取決於您是否在免費基本標準儲存體優化定價層布建Azure 搜尋服務Maximum limits on storage, workloads, and quantities of indexes, documents, and other objects depend on whether you provision Azure Search at Free, Basic, Standard, or Storage Optimized pricing tiers.

  • 免費 的是 Azure 訂用帳戶隨附的多租用戶共用服務。Free is a multi-tenant shared service that comes with your Azure subscription.

  • 基本會針對生產環境工作負載提供較小規模的專用計算資源。Basic provides dedicated computing resources for production workloads at a smaller scale.

  • 標準是在專用的機器上執行,在各層級具有更多的儲存和處理容量。Standard runs on dedicated machines with more storage and processing capacity at every level. 標準共有四個等級︰S1、S2、S3 及 S3 HD。Standard comes in four levels: S1, S2, S3, and S3 HD.

  • 儲存體優化會在儲存體、儲存體頻寬和記憶體總計高於標準的專用電腦上執行。Storage Optimized runs on dedicated machines with more total storage, storage bandwidth, and memory than Standard. 儲存體優化分為兩個層級:L1 和 L2Storage Optimized comes in two levels: L1 and L2


從7月1日起, 所有層均已正式運作, 包括儲存體優化層。As of July 1, all tiers are generally available, including the Storage Optimized tier. 您可以在 [定價詳細資料] 頁面上找到所有定價。All pricing can be found on the Pricing Details page.

S3 高密度 (S3 HD) 是針對特定工作負載所設計:多租用戶和大量的小型索引 (每個索引有 1 百萬份文件,每個服務有三千個索引)。S3 High Density (S3 HD) is engineered for specific workloads: multi-tenancy and large quantities of small indexes (one million documents per index, three thousand indexes per service). 這一層不提供索引子功能This tier does not provide the indexer feature. 在 S3 HD 上,資料擷取必須利用推送方法,使用 API 呼叫以將資料從來源推送到索引。On S3 HD, data ingestion must leverage the push approach, using API calls to push data from source to index.


服務會佈建在特定層。A service is provisioned at a specific tier. 跨層以取得容量牽涉到佈建新服務 (未提供就地升級)。Jumping tiers to gain capacity involves provisioning a new service (there is no in-place upgrade). 如需詳細資訊,請參閱選擇 SKU 或階層For more information, see Choose a SKU or tier. 若要深入了解如何在已佈建的服務內調整容量,請參閱調整適用於查詢和編製索引工作負載的資源等級To learn more about adjusting capacity within a service you've already provisioned, see Scale resource levels for query and indexing workloads.

訂用帳戶限制Subscription limits

您可以在訂用帳戶內建立多個服務。You can create multiple services within a subscription. 每一個都可以在特定層布建。Each one can be provisioned at a specific tier. 您只受限於每一層所允許的服務數目。You're limited only by the number of services allowed at each tier. 例如,您最多可在基本層建立 12 個服務,並在同一個訂用帳戶內的 S1 層另外建立 12 個服務。For example, you could create up to 12 services at the Basic tier and another 12 services at the S1 tier within the same subscription. 如需各層的詳細資訊,請參閱選擇 Azure 搜尋服務的 SKU 或階層。For more information about tiers, see Choose an SKU or tier for Azure Search.

最大服務限制可以視要求引發。Maximum service limits can be raised upon request. 如果您需要相同訂用帳戶內的更多服務,請聯絡 Azure 支援。If you need more services within the same subscription, contact Azure Support.

ResourceResource 免費1Free1 基本Basic S1S1 S2S2 S3S3 S3 HDS3 HD L1L1 L2L2
服務數目上限Maximum services 11 1616 1616 88 66 66 66 66
搜尋單位的最大縮放數(SU)2Maximum scale in search units (SU)2 N/AN/A 3 SU3 SU 36 SU36 SU 36 SU36 SU 36 SU36 SU 36 SU36 SU 36 SU36 SU 36 SU36 SU

1 免費服務是根據共用而非專用的資源。1 Free is based on shared, not dedicated, resources. 共用資源上不支援相應增加。Scale-up is not supported on shared resources.

2搜尋單位是計費單位,配置為複本或資料分割2 Search units are billing units, allocated as either a replica or a partition. 您需要這兩種資源才能進行儲存、編製索引及查詢作業。You need both resources for storage, indexing, and query operations. 若要深入了解 SU 計算,請參閱針對查詢和索引工作負載調整資源層級To learn more about SU computations, see Scale resource levels for query and index workloads.

儲存體限制Storage limits

儲存體受限於磁碟空間,或者索引、文件或其他高層級資源的「數目上限」,取決於何者較早出現。Storage is constrained by disk space or by a hard limit on the maximum number of indexes, document, or other high-level resources, whichever comes first. 下表記載儲存體限制。The following table documents storage limits. 如需索引、檔和其他物件的最大限制,請參閱依資源的限制For maximum limits on indexes, documents, and other objects, see Limits by resource.

ResourceResource 免費Free 基本1Basic1 S1S1 S2S2 S3S3 S3 HD2S3 HD2 L1L1 L2L2
服務等級協定(SLA)3Service level agreement (SLA)3 No yesYes Yes Yes Yes Yes Yes Yes
每個資料分割的儲存體Storage per partition 50 MB50 MB 2 GB2 GB 25 GB25 GB 100 GB100 GB 200 GB200 GB 200 GB200 GB 1 TB1 TB 2 TB2 TB
每個服務的分割區Partitions per service N/AN/A 11 1212 1212 1212 33 1212 1212
分割區大小Partition size N/AN/A 2 GB2 GB 25 GB25 GB 100 GB100 GB 200 GB200 GB 200 GB200 GB 1 TB1 TB 2 TB2 TB
複本數Replicas N/AN/A 33 1212 1212 1212 1212 1212 1212

1 [基本] 具有一個固定的磁碟分割。1 Basic has one fixed partition. 在這一層,會使用額外的搜尋單位來配置更多複本來增加查詢工作負載。At this tier, additional search units are used for allocating more replicas for increased query workloads.

2 s3 HD 具有三個磁碟分割的固定限制,低於 S3 的分割區限制。2 S3 HD has a hard limit of three partitions, which is lower than the partition limit for S3. 較低的分割區限制是因為 S3 HD 的索引計數較高。The lower partition limit is imposed because the index count for S3 HD is substantially higher. 假設計算資源 (儲存體和處理) 和內容 (索引和文件) 的服務限制都存在,會先達到內容限制。Given that service limits exist for both computing resources (storage and processing) and content (indexes and documents), the content limit is reached first.

3專用資源上的計費服務會提供服務等級協定。3 Service level agreements are offered for billable services on dedicated resources. 免費服務和預覽功能不提供 SLA。Free services and preview features have no SLA. 對於可計費服務,SLA 會在您為您的服務佈建足夠的備援性時生效。For billable services, SLAs take effect when you provision sufficient redundancy for your service. 查詢(讀取) Sla 需要兩個或多個複本。Two or more replicas are required for query (read) SLAs. 查詢和索引(讀寫) Sla 需要三個以上的複本。Three or more replicas are required for query and indexing (read-write) SLAs. 資料分割數目不是 SLA 的考慮。The number of partitions isn't an SLA consideration.

索引限制Index limits

ResourceResource 免費Free 基本 1Basic 1 S1S1 S2S2 S3S3 S3 HDS3 HD L1L1 L2L2
索引上限Maximum indexes 33 5 或 155 or 15 5050 200200 200200 每個分割區 1000 個或每個服務 3000 個1000 per partition or 3000 per service 1010 1010
每個索引的簡單欄位數目上限Maximum simple fields per index 10001000 100100 10001000 10001000 10001000 10001000 10001000 10001000
每個索引的複雜集合欄位數目上限Maximum complex collection fields per index 4040 4040 4040 4040 4040 4040 4040 4040
每份檔在所有複雜集合中的元素數目上限Maximum elements across all complex collections per document 30003000 30003000 30003000 30003000 30003000 30003000 30003000 30003000
複雜欄位的最大深度Maximum depth of complex fields 1010 1010 1010 1010 1010 1010 1010 1010
每個索引的建議工具上限Maximum suggesters per index 11 11 11 11 11 11 11 11
每個索引的評分設定檔上限Maximum scoring profiles per index 100100 100100 100100 100100 100100 100100 100100 100100
每個設定檔的函式上限Maximum functions per profile 88 88 88 88 88 88 88 88

1在2017年12月之前建立的基本服務在索引上有較低的限制 (5 而不是 15)。1 Basic services created before December 2017 have lower limits (5 instead of 15) on indexes. 基本層是唯一具有較低限制 (每個索引 100 個欄位) 的 SKU。Basic tier is the only SKU with a lower limit of 100 fields per index.

文件限制Document limits

截至 2018 年 10 月,在任何區域中任何計費層 (基本、S1、S2、S3、S3 HD) 建立的任何新的服務,都不再有任何文件限制。As of October 2018, there are no longer any document limits for any new service created at any billable tier (Basic, S1, S2, S3, S3 HD) in any region. 雖然自 2017 年 11 月/12 月以來,大部分地區有無限制的文件計數,但仍有五個地區繼續實施文件限制。While most regions have had unlimited document counts since November/December 2017, there were five regions that continued to impose document limits. 根據您建立搜尋服務的時間和地點,您可能正在執行仍受限於文件限制的服務。Depending on when and where you created a search service, you might be running a service that is still subject to document limits.

若要判斷您的服務是否有文件限制,請檢查服務概觀頁面中的 [使用量] 圖格。To determine whether your service has document limits, check the Usage tile in the overview page of your service. 文件計數無限制,或受制於以層為基礎的限制。Document counts are either unlimited, or subject to a limit based on tier.


先前具有文件限制的區域Regions previously having document limits

如果入口網站指出文件限制,則您的服務可能是在 2017 年底之前建立,或在使用較低容量叢集來裝載 Azure 搜尋服務的資料中心上建立:If the portal indicates a document limit, your service was either created before late 2017, or it was created on a data center using lower-capacity clusters for hosting Azure Search services:

  • 澳大利亞東部Australia East
  • 東亞East Asia
  • 印度中部Central India
  • 日本西部Japan West
  • 美國中西部West Central US

受制於文件限制的服務適用於下列最大限制:For services subject to document limits, the following maximum limits apply:

免費Free 基本Basic S1S1 S2S2 S3S3 S3 HDS3 HD
10,00010,000 1 百萬1 million 每個分割區 1500 萬個或每個服務 1 億 8 千萬個15 million per partition or 180 million per service 每個分割區 6000 萬個或每個服務 7 億 2 千萬個60 million per partition or 720 million per service 每個分割區 1 億 2 千萬個或每個服務 14 億個120 million per partition or 1.4 billion per service 每個索引 1 百萬個或每個分割區 2 億個1 million per index or 200 million per partition

如果您的服務具有封鎖您的限制,請建立新的服務,然後將所有內容重新發佈至該服務。If your service has limits that are blocking you, create a new service and then republish all content to that service. 沒有任何機制可以在幕後順暢地將您的服務重新佈建到新硬體上。There is no mechanism for seamlessly reprovisioning your service onto new hardware behind the scenes.


對於 2017 年底之後建立的 S3 高密度服務,已移除每個分割區 2 億份文件的限制,但保留每個索引 100 萬份文件的限制。For S3 High Density services created after late 2017, the 200 million document per partition has been removed but the 1 million document per index limit remains.

每個 API 呼叫的文件大小限制Document size limits per API call

呼叫「索引 API」時的文件大小上限大約是 16 MB。The maximum document size when calling an Index API is approximately 16 megabytes.

文件大小是索引 API 要求主體大小的實際限制。Document size is actually a limit on the size of the Index API request body. 由於您可以一次將多份文件整批傳遞給「索引 API」,因此大小限制實際上取決於批次中的文件數量。Since you can pass a batch of multiple documents to the Index API at once, the size limit realistically depends on how many documents are in the batch. 針對具有單一文件的批次,文件大小上限為 16 MB 的 JSON。For a batch with a single document, the maximum document size is 16 MB of JSON.

為了降低文件大小,請記得從要求中排除不可查詢的資料。To keep document size down, remember to exclude non-queryable data from the request. 影像和其他二進位資料無法執行查詢,而且不應該儲存於索引中。Images and other binary data are not directly queryable and shouldn't be stored in the index. 若要將不可搜尋的資料整合到搜尋結果,請定義不可搜尋的欄位,將 URL 參考儲存於資源中。To integrate non-queryable data into search results, define a non-searchable field that stores a URL reference to the resource.

索引子限制Indexer limits

最長的執行時間是為了提供整體服務的平衡和穩定性, 但較大的資料集所需的索引時間可能比允許的最大值還多。Maximum running times exist to provide balance and stability to the service as a whole, but larger data sets might need more indexing time than the maximum allows. 如果索引作業無法在允許的時間上限內完成,請按照排程嘗試執行索引作業。If an indexing job cannot complete within the maximum time allowed, try running it on a schedule. 排程器會追蹤索引狀態。The scheduler keeps track of indexing status. 如果排定的索引作業因故中斷,索引子可以在下次排定的執行時間繼續從上次停止處進行。If a scheduled indexing job is interrupted for any reason, the indexer can pick up where it last left off at the next scheduled run.

ResourceResource 免費 1Free 1 基本 2Basic 2 S1S1 S2S2 S3S3 S3 HD 3S3 HD 3 L1L1 L2L2
索引子上限Maximum indexers 33 5 或 155 or 15 5050 200200 200200 N/AN/A 1010 1010
資料來源上限Maximum datasources 33 5 或 155 or 15 5050 200200 200200 N/AN/A 1010 1010
技能集上限為 4Maximum skillsets 4 33 5 或 155 or 15 5050 200200 200200 N/AN/A 1010 1010
每次叫用的索引編製負載上限Maximum indexing load per invocation 10,000 份文件10,000 documents 僅限制文件上限Limited only by maximum documents 僅限制文件上限Limited only by maximum documents 僅限制文件上限Limited only by maximum documents 僅限制文件上限Limited only by maximum documents N/AN/A 無限制No limit 無限制No limit
最小排程Minimum schedule 5 分鐘5 minutes 5 分鐘5 minutes 5 分鐘5 minutes 5 分鐘5 minutes 5 分鐘5 minutes 5 分鐘5 minutes 5 分鐘5 minutes 5 分鐘5 minutes
執行時間上限 5Maximum running time 5 1-3 分鐘1-3 minutes 24 小時24 hours 24 小時24 hours 24 小時24 hours 24 小時24 hours N/AN/A 24 小時24 hours 24 小時24 hours
影像分析的認知搜尋技能集或 Blob 索引適用的執行時間上限 5Maximum running time for cognitive search skillsets or blob indexing with image analysis 5 3-10 分鐘3-10 minutes 2 小時2 hours 2 小時2 hours 2 小時2 hours 2 小時2 hours N/AN/A 2 小時2 hours 2 小時2 hours
Blob 索引子︰Blob 大小上限,MBBlob indexer: maximum blob size, MB 1616 1616 128128 256256 256256 N/AN/A 256256 256256
Blob 索引子︰從 Blob 擷取的內容字元數上限Blob indexer: maximum characters of content extracted from a blob 32,00032,000 64,00064,000 4 百萬4 million 4 百萬4 million 4 百萬4 million N/AN/A 4 百萬4 million 4 百萬4 million

1 免費服務有索引子執行時間上限,針對 Blob 來源為 3 分鐘,針對其他所有資料來源為 1 分鐘。1 Free services have indexer maximum execution time of 3 minutes for blob sources and 1 minute for all other data sources. 對於呼叫認知服務的 AI 索引, 免費服務限制為每天20個免費交易, 其中的交易會定義為成功通過擴充管線的檔。For AI indexing that calls into Cognitive Services, free services are limited to 20 free transactions per day, where a transaction is defined as a document that successfully passes through the enrichment pipeline.

2 2017 年12月之前建立的基本服務在索引子、資料來源和技能集上有較低的限制 (5 而不是 15)。2 Basic services created before December 2017 have lower limits (5 instead of 15) on indexers, data sources, and skillsets.

3 S3 HD 服務不包含索引子支援。3 S3 HD services do not include indexer support.

4 每個技能集上限為 30 個技術。4 Maximum of 30 skills per skillset.

5 在執行時間方面,Azure Blob 索引中的認知搜尋工作負載和映像分析較一般文字索引短。5 Cognitive search workloads and image analysis in Azure blob indexing have shorter running times than regular text indexing. 影像分析和自然語言處理會耗用大量運算資源,並且需要大量的可用處理能力。Image analysis and natural language processing are computationally intensive and consume disproportionate amounts of available processing power. 執行時間已減少,佇列中的其他作業才有機會執行。Running time was reduced to give other jobs in the queue an opportunity to run.

同義字限制Synonym limits

允許的同義字對應數目上限會依定價層而有所不同。The maximum number of synonym maps allowed varies by pricing tier. 每個規則最多可以有20個擴充, 其中的擴充是 equivalvent 的詞彙。Each rule can have up to 20 expansions, where an expansion is an equivalvent term. 例如, 假設有「cat」, 與 "小貓"、"貓科" 和 "felis" (貓的 genus) 的關聯會計算為3個擴充。For example, given "cat", association with "kitty", "feline", and "felis" (the genus for cats) would count as 3 expansions.

ResourceResource 免費Free 基本Basic S1S1 S2S2 S3S3 S3-HDS3-HD L1L1 L2L2
同義字地圖的最大值Maximum synonym maps 33 33 55 1010 2020 2020 1010 1010
每個對應的規則數目上限Maximum number of rules per map 50005000 2000020000 2000020000 2000020000 2000020000 2000020000 2000020000 2000020000

每秒查詢數目 (QPS)Queries per second (QPS)

每個客戶必須獨立開發 QPS 估計值。QPS estimates must be developed independently by every customer. 索引大小和複雜性、查詢大小和複雜性、流量,這三者是 QPS 的主要決定因素。Index size and complexity, query size and complexity, and the amount of traffic are primary determinants of QPS. 不知道這些因素,便無法提供有意義的估計值。There is no way to offer meaningful estimates when such factors are unknown.

計算在專用資源 (基本和標準層) 上執行的服務,更容易預測估計值。Estimates are more predictable when calculated on services running on dedicated resources (Basic and Standard tiers). 由於可控制較多的參數,所以能更準確地估計 QPS。You can estimate QPS more closely because you have control over more of the parameters. 如需有關如何進行估計的指引,請參閱 Azure 搜尋服務的效能與最佳化For guidance on how to approach estimation, see Azure Search performance and optimization.

針對儲存體優化層, 您應該預期較低的查詢輸送量和比標準層更高的延遲。For the Storage Optimized tiers, you should expect a lower query throughput and higher latency than the Standard tiers. 評估您將遇到之查詢效能的方法, 與標準層相同。The methodology for estimating the query performance you'll experience is the same as the Standard tiers.

對「文字分析」發出呼叫以進行實體辨識關鍵片語擷取情感分析語言偵測認知搜尋管線會受到資料限制約束。A cognitive search pipeline that makes calls to a Text Analytics resource for entity recognition, key phrase extraction, sentiment analysis, and language detection is subject to data limits. 記錄的大小上限應為50000個字元, 如所測量String.LengthThe maximum size of a record should be 50,000 characters as measured by String.Length. 如果您需要先分割資料,再將該資料傳送至情感分析器,請使用文字分割技能If you need to break up your data before sending it to the sentiment analyzer, use the Text Split skill.

API 要求限制API request limits

  • 每個要求最多 16 MB 1Maximum of 16 MB per request 1
  • 最長 8 KB 的 URL 長度Maximum 8 KB URL length
  • 每個索引上傳、合併、或刪除批次最多包含 1000 個文件Maximum 1000 documents per batch of index uploads, merges, or deletes
  • $orderby 子句中最多 32 個欄位Maximum 32 fields in $orderby clause
  • 最大搜尋詞彙的大小是 utf-8 編碼文字的 32,766 個位元組 (32 KB 減 2 個位元組)Maximum search term size is 32,766 bytes (32 KB minus 2 bytes) of UTF-8 encoded text

1 在「Azure 搜尋服務」中,要求主體的上限是 16 MB,這會針對不受理論上限制約束之個別欄位或集合的內容強加實際限制 (如需有關欄位組合和限制的詳細資訊,請參閱支援的資料類型)。1 In Azure Search, the body of a request is subject to an upper limit of 16 MB, imposing a practical limit on the contents of individual fields or collections that are not otherwise constrained by theoretical limits (see Supported data types for more information about field composition and restrictions).

API 回應限制API response limits

  • 每一頁搜尋結果最多傳回 1000 個文件Maximum 1000 documents returned per page of search results
  • 每個建議 API 要求最多傳回 100 個建議Maximum 100 suggestions returned per Suggest API request

API 金鑰限制API key limits

API 金鑰用於服務驗證。API keys are used for service authentication. 有兩種類型。There are two types. 系統管理金鑰是在要求標頭中指定,並會授與完整的服務讀寫存取。Admin keys are specified in the request header and grant full read-write access to the service. 查詢金鑰為唯讀並在 URL 上指定,且通常會發佈到用戶端應用程式。Query keys are read-only, specified on the URL, and typically distributed to client applications.

  • 每個服務最多 2 個系統管理金鑰Maximum of 2 admin keys per service
  • 每個服務最多 50 個查詢金鑰Maximum of 50 query keys per service