Azure Cognitive Search MergeOrUpdate仅修改可检索字段是否触发重索引

核心问题结论 #

执行MergeOrUpdate操作更新文档时，哪怕你只修改标记为retrievable（可返回、未配置可搜索/可筛选/可排序/可分面等索引属性）的字段，对应文档也会触发完整重索引流程，平台不存在“仅修改非索引属性字段就跳过重索引”的优化逻辑。

成本测算与选型判断 #

你可以结合以下实际规则对比两种方案的开销，选择适配业务场景的方案：

• 索引更新侧的成本规则
  Azure Cognitive Search的写入操作按调用次数计费，和单次修改的字段数量无关：每调用一次MergeOrUpdate就算一次写操作，不管改1个retrievable字段还是修改全量字段，单次操作的计费额度一致。
  重索引过程会消耗你购买的搜索单位（SU）的计算资源：如果是大批量文档更新，SU配置不足时会出现写入队列堆积、前端搜索请求延迟升高的问题。如果你的retrievable字段内容体积较大（比如长文本、序列化的大对象），还会额外占用索引存储配额，这部分存储成本也要纳入核算。
• 两种方案的优劣势对比
  • 方案1：将字段纳入搜索索引
    优势是查询时可以直接一次性返回全量结果，不需要额外跳转查询，链路短、查询延迟低，不会给SQL Server增加额外读压力。
    劣势是每次字段更新都要触发索引重写，如果字段更新频率极高（比如秒级/分钟级持续有大量文档更新），会持续占用SU资源，可能影响核心搜索业务的稳定性。
  • 方案2：查询索引后从SQL Server拉取对应字段
    优势是不需要承担该字段的索引更新成本，不会因为这个字段的频繁更新占用搜索资源。
    劣势是每次搜索请求拿到结果主键后，都要额外发一次批量查询到SQL Server取字段值，链路多一跳，整体查询延迟会升高；高并发查询场景下还会给SQL Server造成不小的读压力，需要额外核算SQL读扩容、批量查询性能优化的成本。
• 选型参考标准
  • 若该字段更新频率低（天级/小时级更新，单批次更新量占总文档比例低于10%）、业务查询并发高，优先选择将字段纳入索引，整体性价比更高。
  • 若该字段更新频率极高（分钟级千/万级文档持续更新）、字段内容体积大、业务查询并发低，优先选择查询后从SQL Server拉取数据，避免频繁重索引挤占核心搜索的资源。

内容的提问来源于stack exchange，提问作者Marcelo Janazi