Segment Merge 的触发条件

做的事：真实用单文档写入+refresh的方式重复30次，按理论应该攒出30个segment，看实际会剩下多少个

代码真实循环30次，每次都是: POST /mg_test/_doc {"n": i} 紧跟着 POST /mg_test/_refresh GET /_cat/segments/mg_test GET /mg_test/_stats/merge

验证：30次单文档refresh之后，真实只剩3个segment，而不是理论上的30个

_cat/segments真实只剩3条记录:
→ _l (generation=21, docs=10)
→ _v (generation=31, docs=19)
→ _w (generation=32, docs=1)

_stats/merge:
→ total: 3   ← 真实已经发生了3次合并
→ total_docs: 39   ← 真实合并过程里总共处理了39个文档（有的文档被多次合并路径处理）
→ total_time_in_millis: 25

这组真实结果直接证明了：全程我没有手动调用过一次force_merge，但segment数量真实从理论上应该攒出来的30个，被自动压缩到了只剩3个。generation这个编号真实从1路涨到了32（本次实测最后几个segment的generation是21、31、32这种跳跃很大的数字），说明中间真实有大量更早生成的generation已经在后台合并过程中被真实消灭掉了——它们的内容被合并进了更大的新segment，原来的小文件被真实删除。

真实理解触发这个自动合并发生的条件是什么

代码ES默认使用TieredMergePolicy这套合并策略，真实在每次refresh（产生新segment）之后都会检查一次是否需要触发合并

验证：真实的触发逻辑不是"攒够多少个segment就强制合并"这种简单规则，而是真实持续评估"小segment堆积到一定程度"这个信号

30次refresh的过程中，真实在后台持续发生着:
→ 若干个相邻的、体积相近的小segment被真实挑出来合并成一个更大的segment
→ 被合并掉的小segment文件真实从磁盘上被删除
→ 这个过程真实不需要等到某个固定的数量阈值，而是每次refresh之后都真实有机会被评估触发

分步演示：从理论上攒出30个segment到自动合并压缩到只剩3个的完整验证

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