性能调优要点

适用于:查询变慢、索引变慢,或服务开始丢弃请求时,按“索引结构、查询设计、服务容量”三个层面逐项排查。

前提

  • 已知道当前索引的字段属性、文档规模与主要查询模式。
  • 能在调整前后对同一组查询做延迟与失败次数的对比(监控方法本页未核对:待核实)。

步骤

步骤
操作
依据(页面要点)
1
精简字段属性:只对需要全文搜索的字段设 searchable,只给确有需要的字段设 filterable、sortable、facetable
过滤、排序、分面会增加存储;过度开启会降低索引效率
2
查询时用 searchFields 限定检索字段
每个可搜索字段都会增加查询的工作量
3
查询时用 select 只返回展示需要的字段
返回内容越多越慢;其余字段可用 Lookup API 按需获取
4
避免高 $skip 值,改用过滤或其他方式分批取数
高 skip 需要排序并处理大量文档
5
避免对高基数字段(如每个文档唯一的 ID 或描述)设置 facetable 与 filterable
高基数字段会消耗大量计算
6
把长的 OR 过滤改为 search.in
例如多个 userid eq 串联时性能下降,search.in 更高效
7
谨慎使用前缀、模糊与正则查询
这类查询需要扫描大量索引项,成本更高
8
根据瓶颈选择扩容方式(见下表)
单查询慢与整体拥塞的解决方法不同

扩容决策

症状
优先动作
说明
整体延迟高,请求积压
增加副本(replicas)
副本提升查询吞吐
单个查询慢,数据量大
增加分区(partitions)
分区拆分数据到更多计算资源;低选择性查询与分面计数可能因并行而加快
索引持续增长,S1 频繁加分区与副本
评估升级到更高层级(如 S2)
页面用假设数字说明:更高层级的内存与 CPU 更强,缓存更多索引内容
正则查询复杂
简化正则或拆分为多个查询
复杂正则是高延迟的常见来源
页面中的价格与拓扑示例为假设数字,不代表官方报价。

参数表

参数或设计
建议
说明
searchFields
只列需要的字段
减少参与检索的字段数
select
只列展示需要的字段
减少返回体积
$skip
避免千级以上的大值
大偏移量延迟显著增加
facet count
只对要展示的分面请求计数
分面计数需额外聚合
大量值过滤
使用 search.in,并指定分隔符
比多个等值比较更快

验证

  • 调整前后用同一组查询、同一区域与层级比较 p50、p95 延迟,以及 429 或失败次数。
  • 注意首次查询通常较慢,因为内容在首次查询后才进入内存缓存(页面写明);对比时应排除冷启动。
  • 扩容后观察副本与分区生效的时间:待核实。

排错表

现象
可能原因
处理
索引变大后变慢
字段属性过度开启,或文档中有不需要的内容
按步骤 1 精简,重新评估索引结构
只有某些查询慢
高 skip、复杂正则、高基数分面
按步骤 4、5、7 调整对应查询
高峰期丢请求
副本或层级不足
按扩容决策增加副本或升级层级
加了分区但没有改善
瓶颈在副本数或查询设计
先检查查询,再考虑副本

限制与待核实

  • 各层级的存储上限、副本与分区上限,以及价格:待核实(2026-11-05 获取)。
  • 页面链接中的大规模索引导入与监控页面本次未读取:待核实。
  • 页面的 Standard S2 示例数字仅为假设,不能作为成本依据。

来源与核对

  • 来源:https://learn.microsoft.com/en-us/azure/search/search-performance-tips
  • read_scope:正文已读(性能建议页面,2026-11-05 抓取)。
  • 待核实(2026-11-05 获取):各层级容量与价格,扩容生效时间。
上一篇
检索延迟与质量基准
下一篇
网络与身份
Loading...
文章列表
分享AI实践与思考
入门
Microsoft Foundry
开发工具
治理与网络
观测与评测
工具与知识
模型与部署
Azure OpenAI
Azure AI Search
性能与基准
索引与分块
概念解释
快速上手
Foundry Tools
RAG 与知识工程
检索质量与评测
数据准备
智能体与工具
评测、观测与安全
企业架构与成本
成本与容量
架构
解决方案场景
文档与服务
知识与分析
样例与学习资源
附录