CockroachDB自动添加的无序rowid列是否影响排序及范围扫描

为什么会自动添加rowid列 #

• CockroachDB是基于KV结构的分布式数据库，所有表数据必须依赖主键作为唯一标识映射到底层KV键值对。如果用户建表时没有显式声明主键，系统就会自动创建一个名为rowid的INT类型隐式主键列，列值由数据库自动生成填充，不需要用户手动维护。

rowid是否放弃了排序有序性 #

• 这个列从设计上从来没有放弃有序性，你看到的值“看起来无序”是生成逻辑刻意做的折中：
  rowid的取值是64位整数，生成规则是把时间戳分量放在最高位，后续拼接节点ID、小范围随机序列值。高位的时间戳保证了同一时间窗口生成的ID整体是有序的，低位的节点ID和随机值是为了把写入打散到不同节点，避免连续自增ID导致的写入热点——如果用完全连续递增的ID当主键，所有新写入请求都会落到集群单个Range对应的节点上，分布式集群的多节点并发写入能力完全发挥不出来；但如果用完全随机的ID，又会丢失数据的时序局部性，把相邻时间写入的数据散落到整个集群的存储位置上，拖垮扫描性能。
  简单说它不是完全有序，也不是完全无序，是全局大致时序有序、局部打散分布的设计。

对范围扫描机制的影响 #

• 这个设计不会破坏范围扫描的正常逻辑，具体影响分场景：
  • 如果你的范围查询是基于业务自定义的显式主键、或者提前建好的二级索引做过滤，rowid完全不参与扫描逻辑，数据库会直接走对应索引的有序结构做范围裁剪，性能和有没有这个隐式列没有关系。
  • 如果查询没有命中任何自定义索引，必须走主键做扫描时，因为rowid保留了高位的时间有序性，针对写入时间范围的扫描依然能利用存储的局部性，不会出现全集群无意义乱扫的情况；同时低位的打散设计还能提升扫描的并发度，不会把所有扫描压力集中到单个节点。
  • 只有一种场景需要额外注意：如果你业务上强依赖严格连续递增的ID做有序范围扫描，不要依赖自动生成的rowid，建表时显式定义符合业务排序需求的主键即可，也可以配合哈希分片索引这类能力平衡写入热点和扫描性能。

内容的提问来源于stack exchange，提问作者Thomas