Elasticsearch Update by Query性能瓶颈问题及优化建议咨询
针对你使用扁平文档架构，通过_update_by_query按fatherId更新文档时出现的耗时波动大、成为瓶颈的问题，给出以下优化建议：
优化分片并行参数：当前
slices=1为单分片执行，改为slices=auto（让ES自动根据分片数分配并行任务）或设置为等于索引分片数的数值，利用多分片并行处理，大幅减少单任务执行时间，降低负载下的耗时波动。调整刷新策略：去掉
refresh=true参数，默认ES会按间隔自动刷新（通常1秒）。强制刷新会在更新后立即触发磁盘写入，高负载下会严重拖慢性能。若需确保更新后可立即查询，可改为refresh=wait_for，等待下一次刷新周期完成后返回，避免同步刷新的开销。改为异步执行：将
wait_for_completion=false，让_update_by_query异步执行，请求会立即返回任务ID，之后可通过_tasks/{task_id}查询执行结果。这样不会占用请求连接，避免高负载下因长时间阻塞导致的超时或波动。确保查询字段的索引效率：检查
fatherId字段类型为keyword且已建立索引。如果是text类型，查询时会进行分词匹配，效率极低；非索引字段会触发全表扫描，这两种情况都会导致耗时波动。保证fatherId为精确匹配的索引字段，让查询阶段快速定位目标文档。重构文档架构减少更新范围：扁平架构下更新父亲属性需要修改所有子/女文档，若
fatherId对应文档数量大，单次更新的文档量会非常可观。考虑改用父子文档关系或嵌套文档，将祖父、父亲的属性单独存储为父文档，子/女文档仅保留关联ID，更新父亲属性时只需修改单个父文档，避免批量更新子文档的开销。限制请求速率避免冲击集群：当前
requests_per_second=-1不限制更新速率，高负载下会瞬间压垮ES节点。根据集群负载设置合理的速率值（如requests_per_second=500），平滑更新请求，避免因集群资源耗尽导致的耗时突增。利用路由缩小扫描范围：索引文档时指定
routing=fatherId，将同一fatherId的所有文档路由到同一个分片。执行_update_by_query时添加routing=ABC参数，让ES仅扫描目标分片，而非所有分片，大幅减少查询和更新的范围。缓存目标文档ID批量更新：若同一
fatherId频繁更新，可先通过一次查询获取所有目标文档的ID并缓存，后续更新直接使用_bulk接口批量更新这些ID对应的文档，跳过_update_by_query的重复查询阶段，提升更新效率。排查集群资源瓶颈：检查ES节点的CPU、内存、磁盘IO使用率，高负载下若某类资源耗尽（如磁盘IO过高），会导致耗时波动。针对性升级硬件（如改用SSD磁盘）、调整分片分布（避免热点分片）、增加节点分担负载。
合并重复更新请求：若短时间内有多个针对同一
fatherId的更新请求，将这些请求合并为一次更新操作，减少ES的处理次数，降低集群压力。
内容的提问来源于stack exchange，提问作者Sagar Rout
