在这个Chinese post的主题中，我发现了下面的语句，它提供了一些关于TieredMergePolicy优于LogByteSizeMergePolicy的好处的见解，LogByteSizeMergePolicy是Lucene在TieredMergePolicy之前的默认合并策略：
TieredMergePolicy和LogByteSizeMergepolicy的区别在于前者可以合并非相邻的线段，并且区分了一次允许合并的最大线段数setMaxMergeAtOnce(int v)和一个层中允许的最大线段数setSegmentsPerTier(double v)。
对于TieredMergePolicy的更广泛的解释，一个很好的来源是github上对该类的评论。以下信息来自该来源，并在Apache 2许可证下提供：
合并大小大致相等的段，但每层允许的段数受限。这类似于LogByteSizeMergePolicy，不同之处在于此合并策略能够合并不相邻的段，并将一次合并的段数（setMaxMergeAtOnce）与每层允许的段数（setSegmentsPerTier）分开。此合并策略也不会过度合并（即级联合并）。
对于正常合并，此策略首先计算索引中允许的段数的“预算”。如果索引超出预算，则此策略将按大小递减对段进行排序（按删除百分比按比例分配），然后查找成本最低的合并。合并成本由合并的“偏差”和（最大段的大小除以最小段的大小）、总合并大小和回收的删除百分比，以便优先选择具有较低偏斜、较小大小和回收更多删除的合并。
如果合并将产生大于'setMaxMergedSegmentMB'的段，则该策略将合并较少的段（如果该段有删除，则一次合并1个），以使段大小保持在预算之内。

注意：此策略可自由合并不相邻的段;如果这是一个问题，请使用'LogMergePolicy'。
注意：此策略始终按段的字节大小合并，始终按删除百分比按比例分配
注意从Lucene 7.5开始，有几处变更：+'findForcedMerges'和'findForcedDeletesMerges'）在默认情况下遵守最大段大小。+当使用'maxSegmentCount'而不是1调用'findForcedmerges'时，产生的索引并不保证有〈='maxSegmentCount'个段。相反，它是基于“尽力而为”的原则。具体来说，计算理论上的理想段大小，并添加25%的“fudge因子”作为新的'+'findForcedDeletesMerge'不会产生大于'maxSegmentSize'的段。

TieredMergePolicy首先计算索引中应包含多少段的允许“预算”，方法是计算给定总索引大小、最小段大小时“完美对数阶梯”需要多少步（已被锁定），立即合并，以及允许您设置允许宽度的新配置maxSegmentsPerTier楼梯中每个楼梯的（段数）。这很好，因为它将一次合并多少段与楼梯可以有多宽解耦。