以柏睿数据内存分布式数据库RapidsDB来说明的话，自动优化体现在2个阶段：数据入库过程和数据入库后。我这里重点分享一下数据入库后。
基本实现手段如下：我们都知道如果表中的行在所有行段中都是全局排序的，那么列式表的性能最好。实际上，在连续写入的情况下，维持这样的顺序是极难的。
RapidsDB使用了一种高级的算法，允许它在新增或更新数据时尽可能保持有序。这个过程被称为background merger，并且为使行段的数据顺序能够得到持续优化，则该过程会一直在后台自动运行。
当background merger在运行过程中，在库内数据被增删改等改变时，它会停止到当前任务并且重新开始。鉴于每次只处理一小块行段数据，所以被停止的任务影响的只是少量的数据。只有在大量的更新工作负载下，重新排序处理效率才会显著减慢，这是因为另一个机制pessimistic merger会锁定当前正在处理的行段。用户也可以通过运行命令OPTIMIZE TABLE手动触发pessimistic merger。我们将在下面解释如何决定是否有必要进行该指令，并如何运行它。
RapidsDB使用sorted row segment group（排序行段组）的概念来描述参与排序的一组行段。即行段重新排序的过程，并且对于一个行段而言，其最小的行号不小于其之前的任何行段中最大的行号，则这些行段形成排序的行段组。这里所描述的一行比另一行小，是代表该行的CLUSTERED COLUMNSTORE键的列值比另一行的列值小。
如果数据有一个完美的全局顺序，它将由一个排序的行段组组成。如果刚入库的原始数据是以完全随机的顺序排列的，那么它会包含与行段一样多的排序行段组。background merger的任务逻辑就是重新组织行段之间的行，即尽量减少排序的行段组的数量。
