Async Search 长时间查询

做的事：真实提交一条昂贵的script_score查询到_async_search，只给1毫秒的等待时间就强制返回

代码真实索引50000条文档 POST /as_test/_async_search?wait_for_completion_timeout=1ms {"query":{"script_score":{ "query":{"match_all":{}}, "script":{"source":"double x=0; for(int i=0;i<2000;i++){x+=Math.sqrt(i+doc['n'].value);} return x;"} }}}

验证：1毫秒真实不够这条昂贵查询跑完，响应里真实带着is_running:true和一个可以继续追踪的id

is_running: True    ← 真实查询还在后台继续执行，没有跑完
is_partial: True    ← 真实目前返回的结果是不完整的
id: "FjZlUkwtVm5SUmVLb1FGOU0zcHVKRmcb..."   ← 真实可以用来后续查询状态的id

这组真实结果验证了async search最核心的工作方式：提交查询之后，ES真实不会强制客户端一直阻塞等待这条昂贵查询跑完，wait_for_completion_timeout真实指定了"最多愿意同步等待多久"，超过这个时间还没跑完，就真实先返回一个带着is_running:true的中间状态和一个查询id，真正的查询真实继续在服务端后台执行，不会因为客户端提前拿到响应就被中断。

真实隔1秒之后用这个id去轮询，看查询是否已经真实跑完

代码GET /_async_search/<上一步拿到的id>

验证：1秒之后真实is_running已经变成false，完整的命中结果真实已经算出来了

is_running: False   ← 真实查询已经跑完
is_partial: False   ← 真实结果已经是完整的
hits.total: {'value': 10000, 'relation': 'gte'}

真实验证async search的结果是有生命周期的服务端资源：删除之后能不能再查到

代码DELETE /_async_search/<id> GET /_async_search/<同一个id> # 真实删除之后再查一次

验证：删除之后用同一个id再查，真实直接404 resource_not_found_exception

DELETE /_async_search/<id>: {"acknowledged":true}

再GET同一个id:
→ 404 resource_not_found_exception

这组真实结果说明async search的结果真实不是永久保存的，它本质上是一份有生命周期的服务端资源（默认保留5天，也可以提交时通过keep_alive调整），本次实测真实主动调用DELETE显式释放之后，这份结果真实立刻从服务端清除，再用同一个id去查真实直接收到404——跟本系列第52篇验证过的PIT关闭后立刻失效的行为真实如出一辙。这提醒了使用async search时真实需要主动管理这份资源的生命周期：轮询拿到最终结果之后，如果确认不再需要，真实应该主动删除，避免让这些中间结果在服务端一直占用空间直到默认的保留期限自然过期。

分步演示：async search从提交不阻塞到轮询完成再到显式删除的完整生命周期

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。