在分段的思想下，对数据写操作的过程如下。
为了提升写的性能，Lucene并没有每新增一条数据就增加一个段，而是采用延迟写的策略，每当有新增的数据时，就将其先写入内存中，然后批量写入磁盘中。若有一个段被写到硬盘，就会生成一个提交点，提交点就是一个用来记录所有提交后的段信息的文件。一个段一旦拥有了提交点，就说明这个段只有读的权限，失去了写的权限；相反，当段在内存中时，就只有写数据的权限，而不具备读数据的权限，所以也就不能被检索了。从严格意义上来说，Lucene或者Elasticsearch并不能被称为实时的搜索引擎，只能被称为准实时的搜索引擎。
写索引的流程如下。
因为索引检索的过程是：查询所有段中满足查询条件的数据，然后对每个段里查询的结果集进行合并，所以为了控制索引里段的数量，我们必须定期进行段合并操作。但是如果每次合并全部的段，则将造成很大的资源浪费，特别是“大段”的合并。
所以Lucene现在的段合并思路是：根据段的大小先将段进行分组，再将属于同一组的段进行合并。但是由于对超级大的段的合并需要消耗更多的资源，所以Lucene会在段的大小达到一定规模，或者段里面的数据量达到一定条数时，不会再进行合并。所以Lucene的段合并主要集中在对中小段的合并上，这样既可以避免对大段进行合并时消耗过多的服务器资源，也可以很好地控制索引中段的数量。
段合并的主要参数如下。
段合并相关的动作主要有以下两个：
在段合并前对段的大小进行了标准化处理，通过log MergeFactor SegmentSize
计算得出，其中，MergeFactor表示一次合并的段的数量，Lucene默认该数量为10；SegmentSize表示段的实际大小。通过上面的公式计算后，段的大小更加紧凑，对后续的分组更加友好。
段分组的步骤如下：
在找到满足条件的mergeFactor个段时，就需要开始合并了。但是在满足合并条件的段大于mergeFactor时，就需要进行多次合并，也就是说每次依然选择mergeFactor个段进行合并，直到该分组的所有段合并完成，再进行下一分组的查找合并操作。
通过上述几步，如果找到了满足合并要求的段，则将会进行段的合并操作。因为索引里面包含了正向信息和反向信息，所以段合并的操作分为两部分：一个是正向信息合并，例如存储域、词向量、标准化因子等；一个是反向信息的合并，例如词典、倒排表等。在段合并时，除了需要对索引数据进行合并，还需要移除段中已经删除的数据。