Point In Time 与 search_after

做的事：真实打开一个PIT快照，索引10条文档后验证能不能看到一致的结果数

代码真实索引10篇文档: {n:1}...{n:10} POST /pit_test/_pit?keep_alive=1m # 真实打开一个保活1分钟的point in time → 返回一个160字符长的pit id POST /_search {"size":20,"query":{"match_all":{}},"pit":{"id":"<上面的pit id>","keep_alive":"1m"}}

验证：打开PIT之后又新插入1条文档，用同一个PIT查询真实依然只看到原来的10条

PIT打开后，真实又新插入了一条{n:99}并刷新了索引

用同一个PIT继续查询:
→ total hits = 10   ← 真实依然是打开PIT那一刻的文档数量
→ 返回的10条真实都是n=1到n=10，没有n=99

同时不带PIT直接搜索:
→ total hits = 11   ← 真实能看到新插入的那条

真实验证PIT用完之后显式关闭，再用它查询会发生什么

代码DELETE /_pit {"id":""} POST /_search {"size":3,"query":{"match_all":{}},"pit":{"id":"<同一个已关闭的pit id>"}}

验证：关闭后的PIT真实立刻失效，再用它查询直接404报错

DELETE /_pit: {"succeeded":true,"num_freed":1}

再用同一个pit id查询:
→ 404 search_context_missing_exception: "No search context found for id [159]"

这组真实结果说明PIT真实是一种需要主动管理生命周期的资源，不是免费的：打开PIT的时候，ES真实要在每个相关分片上保留一份当时的段（segment）引用，防止这些段在后台合并或删除时被真实回收掉——这意味着PIT开着的时间越长，真实越可能让底层应该被清理的旧数据段继续占用磁盘空间。本次实测真实验证了关闭PIT之后立刻生效，再用这个失效的id查询会真实收到明确的404报错而不是静默返回空结果，这也是为什么官方文档建议翻页流程结束后要真实主动调用DELETE /_pit显式释放，而不是依赖keep_alive超时被动回收——虽然超时机制作为兜底真实存在，但主动释放能更快把资源还给集群。

分步演示：PIT从快照一致性保证到显式关闭后失效的完整验证

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