你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure AI 搜索中的服务限制
对存储、工作负荷以及索引和其他对象的数量的最大限制取决于你是在“免费”、“基本”、“标准”还是“存储优化”定价层上创建 Azure AI 搜索。
“免费”层是 Azure 订阅随附的多租户共享服务。
“基本”层为较小规模的生产工作负荷提供专用计算资源，但与其他租户共享某些网络基础结构。
标准层在专用计算机上运行，在每个级别上都具有更多存储和处理容量。 标准层共有四个级别：S1、S2、S3 和 S3 HD。 S3 高密度 (S3 HD) 旨在用于多租户方案，以及较大数量的小型索引（每个服务 3000 个索引）。 S3 HD 不提供索引器功能，并且数据引入必须使用将数据从源推送到索引的 API。
“存储优化”层在总存储量、存储带宽和内存量比“标准”层更高的专用计算机上运行。 此层面向缓慢变化的大型索引。 “存储优化”层分为两个级别：L1 和 L2。
订阅限制
可创建多个可计费的搜索服务（基本层和更高层级），最多可创建每个区域每层允许的服务数上限。 例如，在同一订阅和区域中，最多可以在基本层创建 16 个服务，并在 S1 层中创建另外 16 个服务。 然后，可以在另一个区域中创建另外 16 个基本服务，即可在同一订阅下创建共 32 个基本服务。 有关层的详细信息，请参阅为 Azure AI 搜索选择层（或 SKU）。
最大服务数限制可以根据请求提高。 如果需要在同一订阅中使用更多服务，请提交支持请求。
| 资源 | 免费 1 | 基本 | S1 | S2 | S3 | S3 HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 每个区域的最大服务数 | 1 | 16 | 16 | 8 | 6 | 6 | 6 | 6 |
| 最大搜索单位数 (SU)2 | 空值 | 3 SU | 36 个 SU | 36 个 SU | 36 个 SU | 36 个 SU | 36 个 SU | 36 个 SU |
1 每个 Azure 订阅可以有一个免费的搜索服务。 免费层基于与其他客户共享的基础结构。 硬件不是专用的，因此不支持纵向扩展，并且存储限制为 50 MB。 长时间处于非活动状态后，可能会删除免费搜索服务，以便为更多服务腾出空间。
2 搜索单位 (SU) 即计费单位，以副本或分区形式分配。 两个都需要。 若要了解有关 SU 组合的详细信息，请参阅估计和管理搜索服务的容量。
服务限制
下表描述了服务级别的 SLA、分区计数和副本计数。
| 资源 | 免费 | 基本 | S1 | S2 | S3 | S3 HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 服务级别协议 (SLA) | 否 | 是 | 是 | 是 | 是 | 是 | 是 | 是 |
| 分区 | 空值 | 3 1 | 12 | 12 | 12 | 3 | 12 | 12 |
| 副本 | 空值 | 3 | 12 | 12 | 12 | 12 | 12 | 12 |
1 基本层支持三个分区和三个副本，在 2024 年 4 月 3 日之后创建的新搜索服务上，总共有 9 个搜索单位 (SU)。 较旧的基本服务限制为一个分区和三个副本。
搜索服务受存储上限限制（分区大小乘以分区数）或者受索引数上限或索引器数上限的硬性限制（以先达者为准）。
服务级别协议 (SLA) 适用于对查询工作负荷具有两个或多个副本的计费服务，或者查询和索引工作负荷的三个或更多个副本。 分区数不属于 SLA 相关考虑因素。 有关详细信息，请参阅 Azure AI 搜索中的可靠性。
免费服务没有固定分区或副本，它们与其他订阅者共享资源。
分区存储 (GB)
每服务的存储限制根据两个因素而异：服务创建日期和区域。 在大多数受支持区域，较新服务的限制更高。
此表显示了存储配额随时间推移以 GB 为增量不断递增的情况。 从 2024 年 4 月开始，在脚注中列出的区域中，更高容量的分区已联机。 更高容量仅限于新的搜索服务。 目前未提供就地升级。
| 服务创建日期 | 基本 | S1 | S2 | S3/HD | L1 | L2 |
|---|---|---|---|---|---|---|
| 2024 年 4 月 3 日之前 | 2 | 25 | 100 | 200 | 1,024 | 2,048 |
| 2024 年 4 月 3 日至 2024 年 5 月 17 日 1 | 15 | 160 | 512 | 1,024 | 1,024 | 2,048 |
| 2024 年 5 月 17 日之后 2 | 15 | 160 | 512 | 1,024 | 2,048 | 4,096 |
1 这些区域中的基本、S1、S2 和 S3 层具有更高的容量存储。 美洲：巴西南部、加拿大中部，加拿大东部、美国东部，美国东部 2，美国中部，美国中北部，美国中南部，美国西部，美国西部 2，美国西部 3、美国中西部。 欧洲：法国中部。 意大利北部、北欧、挪威东部、波兰中部、瑞士北部、瑞典中部、英国南部，英国西部。 中东：阿联酋北部。 非洲：南非北部。 亚太：澳大利亚东部，澳大利亚东南部、印度中部、Jio 印度西部、东亚、东南亚、日本东部、日本西部、韩国中部、韩国南部。
2 L1 和 L2 层具有更高容量的存储。 更多区域将在每个可计费层提供更高的容量。 欧洲：德国北部、德国中西部、瑞士西部。 Azure 政府：得克萨斯州、亚利桑那州、弗吉尼亚州。 非洲：南非北部。 亚太地区：中国北部 3、中国东部 3。
一些区域仍在旧基础结构上运行，但受 4 月 3 日限制的约束。 在创建新服务之前，请查看支持的区域，以确保所选区域提供额外的容量。
索引限制
| 资源 | 免费 | 基本 1 | S1 | S2 | S3 | S3 HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 最大索引数 | 3 | 5 或 15 | 50 | 200 | 200 | 每个分区 1000，或者每个服务 3000 | 10 | 10 |
| 每个索引的最大简单字段数目 2 | 1000 | 100 | 1000 | 1000 | 1000 | 1000 | 1000 | 1000 |
| 每个矢量场的最大维度数 | 4098 | 4098 | 4098 | 4098 | 4098 | 4098 | 4098 | 4098 |
| 每个索引的最大复杂集合 | 40 | 40 | 40 | 40 | 40 | 40 | 40 | 40 |
| 每个文档的所有复杂集合的最大元素数目 3 | 3000 | 3000 | 3000 | 3000 | 3000 | 3000 | 3000 | 3000 |
| 复杂字段的最大深度 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| 每个索引最大建议器数 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| 每个索引的最大计分概要文件数 | 100 | 100 | 100 | 100 | 100 | 100 | 100 | 100 |
| 每个配置文件的最大函数数量 | 8 | 8 | 8 | 8 | 8 | 8 | 8 | 8 |
| 最大索引大小4 | 空值 | 不可用 | 空值 | 1.88 TB | 2.34 TB | 100 GB | 空值 | 空值 |
2 在 2017 年 12 月之前创建的基本服务对索引数的限制较低（为 5 个而不是 15 个）。 基本层是唯一具有下限（每个索引 100 个字段）的层。
2 字段的上限包括复杂集合中的一级字段和嵌套子字段。 例如，如果一个索引包含 15 个字段，并且有两个复杂集合，每个集合有 5 个子字段，则索引的字段计数为 25。 具有大型字段集合的索引可能会很慢。 将字段和属性限制为你需要的字段和属性，并运行索引和查询测试以确保性能可以接受。
3 元素数存在上限，因为大量元素会导致索引所需的存储大量增加。 复杂集合的元素定义为该集合的成员。 例如，假设有一个“酒店”文档中包含“客房”复杂集合，则将“客房”集合中的每个客房视为一个元素。 编制索引期间，索引编制引擎一次可最多安全地处理整个文档中的 3000 个元素。 api-version=2019-05-06 中引入了此限制，且仅适用于复杂集合，不适用于字符串集合或复杂字段。
4 在大多数层上，最大索引大小都是搜索服务上可用的存储。 对于 S2、S3 和 S3 HD，任何索引的最大大小都是表中提供的数字。 适用于 2024 年 4 月 3 日之后创建的搜索服务。
如果你的服务恰好是在更强大的群集上预配的，你可能会发现最大限制有所不同。 这里的限制代表了共同点。 根据上述规范构建的索引可以跨任何区域的等效服务层移植。
文档限制
每个索引的最大文档数为：
- 在基本版、S1、S2、S3 层上为 240 亿个
- 在 S3 HD 层上为 20 亿个
- 在 L1 层上为 2880 亿个
- 在 L2 层上为 5760 亿个
就这些限制而言，复杂集合的每个实例都计为一个单独的文档。
每个文档的最大大小约为 16 MB。 文档大小实际上是索引 API 请求有效负载的大小限制，即 16 MB。 该有效负载可以是单个文档，也可以是一批文档。 对于具有单个文档的批次，最大文档大小是 16 MB JSON。
文档大小适用于将文档上传到搜索服务的推送模式索引。 如果使用索引器进行拉取模式索引，则源文件可以是任意文件大小，但需符合索引器限制。 对于 Blob 索引器，文件大小的限制在更高层中更大。 例如，S1 限制为 128 MB，S2 限制为 256 MB，依此类推。
估算文档大小时，请记住只对那些为搜索方案增加值的字段进行索引，并排除要在要运行的查询中没有任何用途的源字段。
矢量索引大小限制
使用矢量字段为文档编制索引时，Azure AI 搜索会使用提供的算法参数构建内部矢量索引。 这些矢量索引的大小取决于为服务层（或SKU）的矢量搜索保留的内存。 有关管理矢量存储以及使其实现最大化的指导，请参阅矢量索引大小和保持在限制范围内。
矢量限制因以下情况而异：
从 2024 年 4 月开始，新的搜索服务在提供额外容量的区域（即大部分）中具有更高的矢量上限。
此表显示了矢量配额随时间推移以 GB 为增量不断递增的情况。 配额是按分区分配的，因此，如果将新的标准 (S1) 服务扩展到 6 个分区，则总矢量配额为 35 乘以 6。
| 服务创建日期 | 基本 | S1 | S2 | S3/HD | L1 | L2 |
|---|---|---|---|---|---|---|
| 2023 年 7 月 1 日之前 1 | 0.5 | 1 | 6 | 12 | 12 | 36 |
| 2023 年 7 月 1 日至 2024 年 4 月 3 日 2 | 1 | 3 | 12 | 36 | 12 | 36 |
| 2024 年 4 月 3 日至 2024 年 5 月 17 日 3 | 5 | 35 | 150 | 300 | 12 | 36 |
| 2024 年 5 月 17 日之后 4 | 5 | 35 | 150 | 300 | 150 | 300 |
1 早期预览期的初始矢量限制。
2 后期预览期的矢量限制。 以下三个区域没有更高的限制：德国中西部、印度西部、卡塔尔中部。
3 根据受支持层和区域的较大分区分配的更高矢量配额。
4 根据分区大小更新为其他层和区域分配的更高矢量配额。
该服务对搜索服务中的每个分区强制实施矢量索引大小配额。 每个额外分区都会增加可用的矢量索引大小配额。 此配额是一个硬限制，用于确保你的服务保持健康运行，这意味着一旦超过限制，任何进一步的索引尝试将导致失败。 通过删除一些矢量文档或扩展分区释放可用配额后，可以继续进行索引编制。
重要
矢量限制越高，分区大小越大。 在较旧的基础结构上运行的区域受 7 月至第二年 4 月的限制。 查看区域列表，了解分区存储限制的状态。
索引器限制
“最长运行时间”存在的目的是在总体上为服务提供平衡和稳定性，但较大的数据集所需的索引编制时间可能会超过最大值允许的时间。 如果在允许的最长时间内无法完成索引作业，请尝试按计划运行。 计划程序将跟踪索引的状态。 如果计划的索引作业因某种原因而中断，则索引器可以在下一次计划运行时从它上次停止的位置重新开始。
| 资源 | 免费 1 | 基本 2 | S1 | S2 | S3 | S3 HD 3 | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 最大索引器数 | 3 | 5 或 15 | 50 | 200 | 200 | 空值 | 10 | 10 |
| 最大数据源数 | 3 | 5 或 15 | 50 | 200 | 200 | 空值 | 10 | 10 |
| 最大技能组数4 | 3 | 5 或 15 | 50 | 200 | 200 | 空值 | 10 | 10 |
| 每次调用的最大索引编制负载 | 10,000 个文档 | 仅受最大文档的限制 | 仅受最大文档的限制 | 仅受最大文档的限制 | 仅受最大文档的限制 | 空值 | 无限制 | 无限制 |
| 最小计划 | 5 分钟 | 5 分钟 | 5 分钟 | 5 分钟 | 5 分钟 | 5 分钟 | 5 分钟 | 5 分钟 |
| 最长运行时间 5 | 1-3 或 3-10 分钟 | 2 小时或 24 小时 | 2 小时或 24 小时 | 2 小时或 24 小时 | 2 小时或 24 小时 | 不适用 | 2 小时或 24 小时 | 2 小时或 24 小时 |
| Blob 索引器：最大 blob 大小，MB | 16 | 16 | 128 | 256 | 256 | 空值 | 256 | 256 |
| Blob 索引器：从 blob 中提取的内容的最大字符数6 | 32,000 | 64,000 | 4 百万 | 8 百万 | 1600 万 | 不可用 | 4 百万 | 4 百万 |
1 对于免费服务，对于 blob 源，索引器最长执行时间为 3 分钟；对于所有其他数据源，索引器最长执行时间为为 1 分钟。 索引器调用每 180 秒一次。 对于调用 Azure AI 服务的 AI 索引，免费服务的限制是每个索引器每天 20 个免费事务，其中一个事务定义为一个成功通过扩充管道传递的文档（提示：可以重置索引器以重置其计数）。
2 在 2017 年 12 月之前创建的基本服务在索引器、数据源和技能组方面的限制较低（为 5 个而不是 15 个）。
3 S3 HD 服务未包括索引器支持。
4 每个技能组最多拥有 30 项技能。
5 关于索引器的 2 或 24 小时最长持续时间：2 小时的最长持续时间是最常见的，这是你应计划的内容。 它是指在公共环境中运行的索引器，用于卸载计算密集型处理，并为查询留出更多资源。 如果将索引器配置为仅使用分配给搜索服务的基础结构在专用环境中运行，则 24 小时限制适用。 请注意，某些较旧的索引器无法在公共环境中运行，并且这些索引器的处理范围始终是 24 小时。 如果有连续 24 小时运行的未计划索引器，则可以假定这些索引器无法迁移到较新的基础结构。 一般情况下，对于无法在两小时内完成的索引编制作业，请将索引器置于 5 分钟计划中，以便索引器可以从上次中断位置快速继续。 在免费层中，3-10 分钟最大运行时间适用于具有技能组的索引器。
6 最大字符数基于 Unicode 代码单元，特别是 UTF-16。
注意
如索引限制中所述，从支持复杂类型 (2019-05-06) 的最新 API 正式版开始，索引器还针对每个文档的所有复杂集合强制实施 3000 个元素的上限。 这意味着，如果你使用早期 API 版本创建了索引器，则不会受此限制约束。 为了保持最高兼容性，使用 API 旧版本创建，然后使用 API 版本 2019-05-06 或更高版本更新的索引器，仍会从这些限制中2019-05-06。 客户应注意使用极大复杂集合所造成的负面影响（如前所述）；我们强烈建议使用最新 API 正式版创建任何新索引器。
共享专用链接资源限制
索引器可访问专用终结点上通过共享专用链接资源 API 管理的其他 Azure 资源。 本部分介绍与此功能相关的限制。
| 资源 | 免费 | 基本 | S1 | S2 | S3 | S3 HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 专用终结点索引器支持 | 否 | 是 | 是 | 是 | 是 | No | 是 | 是 |
| 使用技能组的索引器的专用终结点支持1 | 否 | No | No | 是 | 是 | No | 是 | 是 |
| 使用技能组和集成矢量化的索引器的专用终结点支持2 | 否 | 是 | 是 | 是 | 是 | No | 是 | 是 |
| 最大专用终结点 | 不可用 | 10 或 30 | 100 | 400 | 400 | 不可用 | 20 | 20 |
| 最大不同资源类型数3 | 空值 | 4 | 7 | 15 | 15 | 不可用 | 4 | 4 |
1 AI 扩充和图像分析属于计算密集型功能，会消耗过多的可用处理能力。 因此，在较低层上禁用了专用连接以确保搜索服务本身的性能和稳定性。
2 2024 年 4 月 3 日之后在分区存储下列出的区域中创建的、在编制索引时运行集成矢量化工作负载的大容量服务支持付费层级中的共享专用链接。 系统必须至少检测到一种正在嵌入数据的技能。
3 不同资源类型的数量计算为在给定搜索服务的所有共享专用链接资源中使用的唯一 groupId 值的数量，而与资源的状态无关。
同义词限制
同义词映射的最大数量因层而异。 每个规则最多可以有 20 个扩展，一个扩展就是一个意义相同的词。 例如，在指定“猫”的情况下，与“猫咪”、“猫科动物”和“猫属”（猫的属）的关联将算作 3 个扩展。
| 资源 | 免费 | 基本 | S1 | S2 | S3 | S3-HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 最大同义词映射数 | 3 | 3 | 5 | 10 | 20 | 20 | 10 | 10 |
| 每个映射的最大规则数 | 5000 | 20000 | 20000 | 20000 | 20000 | 20000 | 20000 | 20000 |
索引别名限制
索引别名的最大数量因层级和服务创建日期而异。 在所有层级中，如果服务是在 2022 年 10 月之后创建的，则别名的最大数量是允许的最大索引数量的两倍。 如果服务是在 2022 年 10 月之前创建的，则限制是允许的索引数。
| 服务创建日期 | 免费 | 基本 | S1 | S2 | S3 | S3-HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 2022 年 10 月之前 | 3 | 5 或 151 | 50 | 200 | 200 | 每个分区 1000，或者每个服务 3000 | 10 | 10 |
| 2022 年 10 月之后 | 6 | 30 | 100 | 400 | 400 | 每个分区 2000 个，或者每个服务 6000 个 | 20 | 20 |
2 2017 年 12 月之前创建的基本服务的索引数限制较低（5 而不是 15）
数据限制（AI 扩充）
调用 Azure AI 语言资源进行实体识别、实体链接、关键短语提取、情绪分析、语言检测和个人信息检测的 AI 扩充管道存在数据限制。 记录的最大大小应为 50,000 个字符，通过 String.Length 进行测量。 如果需要在将数据发送到情绪分析器之前拆分数据，请使用文本拆分技能。
限制
当系统接近峰值容量时，API 请求会受到限制。 对不同 API 的限制行为各不相同。 系统会根据服务的负载动态限制查询 API（搜索/建议/自动完成）和索引 API。 索引 API 和服务操作 API 具有静态请求速率限制。
索引相关操作的静态速率请求限制：
- 列出索引 (GET /indexes)：每个搜索单位每秒限制为 3 个
- 获取索引 (GET /indexes/myindex)：每个搜索单位每秒限制为 10 个
- 创建索引 (POST /indexes)：每个搜索单位每分钟限制为 12 个
- 创建或更新索引 (PUT /indexes/myindex)：每个搜索单位每秒限制为 6 个
- 删除索引 (DELETE /indexes/myindex)：每个搜索单位每分钟限制为 12 个
服务相关操作的静态速率请求限制：
- 服务统计信息 (GET /servicestats)：每搜索单位每秒 4 个
语义排序器限制
语义排序器使用队列系统来管理并发请求。 此系统允许搜索服务每秒获得尽可能多的查询。 达到并发请求限制时，会将其他请求置于队列中。 如果队列已满，则会拒绝进一步的请求，必须重试。
每秒语义排序器查询总数因以下因素而异：
- 搜索服务的层。 队列容量和并发请求限制因层而异。
- 搜索服务中的搜索单位数。 增加并发语义排序器查询最大数量的最简单方法是向搜索服务添加其他搜索单位。
- 区域中可用的语义排序器容量总数。
- 使用语义排序器提供查询所需的时间。 这因搜索服务的繁忙程度而异。
下表根据区域中的可用容量，按层描述语义排名器限制。 可以联系 Microsoft 支持部门请求提高限制。
| 资源 | 基本 | S1 | S2 | S3 | S3-HD | L1 | L2 |
|---|---|---|---|---|---|---|---|
| 最大并发请求数（每个搜索单位） | 2 | 3 | 4 | 4 | 4 | 4 | 4 |
| 最大请求队列大小（每个搜索单位） | 4 | 6 | 8 | 8 | 8 | 8 | 8 |
API 请求限制
查询存在限制，因为未绑定的查询可能会破坏搜索服务的稳定性。 通常，这样的查询是以编程方式创建的。 如果应用程序以编程方式生成搜索查询，则建议将其设计为不会生成无限大小的查询。
存在对有效负载的限制的原因类似，确保搜索服务的稳定性。 此限制适用于整个请求，包括其所有组件。 例如，如果请求批处理多个文档或命令，则整个请求必须符合支持的限制。
如果必须超出受支持的限制，则应测试工作负荷，以便了解预期内容。
除非另有说明，否则以下 API 请求适用于所有可编程接口，包括 Azure SDK。
常规：
- 支持的最大有效负载限制为 16 MB，用于通过 REST API 和 SDK 编制索引和查询请求。
- 最大 8 KB 的 URL 长度（仅适用于 REST API）。
索引 API：
- 每个索引上传、合并或删除的批次最多支持 1,000 个文档。
查询 API：
- $Orderby 子句中最多 32 字段。
- 搜索子句中最多 100,000 个字符。
- 搜索中的最大子句数为 3,000。
- Lucene 会强制实施通配符和正则表达式查询的最大限制。 它会将模式、变体或匹配数上限设为 1,000 个实例。 此限制已实施，以避免引擎过载。
搜索词：
- 支持的最大搜索词大小为 UTF-8 编码文本的 32,766 字节（32 KB 减 2 个字节）。 适用于关键字搜索和矢量搜索的文本属性。
- 支持的前缀搜索和正则表达式搜索的最大搜索词大小为 1,000 个字符。
API 响应限制
- 每页搜索结果最多返回 1,000 个文档
- 每个建议 API 请求最多返回 100 条建议
默认情况下，搜索引擎返回 50 个结果，但最多可以覆盖此参数的最大限制。
API 密钥限制
API 密钥用于服务身份验证。 有两种类型。 管理密钥在请求标头中指定，并授予对服务的完全读写访问权限。 查询密钥是只读密钥并在 URL 上指定，并且通常分发给客户端应用程序。
- 每个服务最多 2 个管理密钥
- 每个服务最多 50 个查询密钥