自增列是数据库的一个重要功能，OceanBase 1.0实现了分布式系统全局自增列，下面简单介绍一些实现细节和思路。本文着重叙述实现上的一些问题和方案，不会涉及特别细节的地方，比如类型，自增值溢出，sql_mode等。
三个原则
功能上，OceanBase自增列遵守三个原则，设计上也是按满足这三个原则来做
1. 多分区全局唯一
2. 语句内连续递增
3. 生成的自增列值比用户显式插入的大
内部存储设计
用一个专门的系统表记录所有自增列的元信息，每个自增列占据一条记录，主要包含如下信息：
sequence_value，sync_value
sequence_value记录已分配的最大自增值，sync_value记录用户显示插入的最大自增值
没有中心分配节点，由各个节点自己访问sequence系统表获取自增列。
全局唯一
按需按段分配。每个分区分配区间长度为固定大小的独立段，不同分区的区间互不重叠。切主后原leader的cache不失效，重新上任后可复用，每新分配一个段都会更新到sequence表。
没有独立的分配线程，由SQL执行线程自己从cache分配，cache更新也由自己完成（rpc执行线程除外）
以"select for update" + "update"保证生成区间的唯一性
按段划分也是为了性能考虑，因为不可能每次都从sequence表获取新的自增值
语句内连续递增
当然，前提是单条insert语句不会跨分区，语句执行插入之前一次性获取所需自增值（按期望自增值个数 + increment + offset计算出所需的最大值），缓存起来,真正插入时只需要访问缓存就可以获得连续递增的自增值。
生成的自增列值比用户显式插入的大
这个原则是为了兼容mysql，语义是指若用户手动指定一个自增值，后续生成的自增值一定要比这个值大，这在单进程下是个很简单的事情，但OceanBase是分布式系统，各个分区分散在不同节点，为了满足这个原则，插入成功后会通知其它节点作本地cache的更新，即各个节点都要检查最新的sync_value是否超过了本地的缓存段，如果超过则需要从sequence表拿新的段更新到本地cache，旧段失效
异常处理
异常情形
RPC不可靠，若节点收不到rpc原则3就破坏了
sequence表不可用，即使RPC准确通知到，若此时sequence表由于分区无主出现短期不可用，那其它节点也无法更新到sync_value, 原则3也破坏了
处理
为了尽快使sync_value在整个集群内生效，并且能处理sequence表不可用的异常，OceanBase以时间间隔T作为刷新sync_value的租约时间，任何请求在获取自增值时会检查当前时间与本地最新一次刷sync_value的时间间隔。如果间隔超过T，主动做一次sync_value的刷新。这样即使rpc丢失或sequence表不可用，只要有新数据插入并且当前时间距离上一次刷新时间超过租约T，一定会主动刷一次。
对于OceanBase，原则3的保证其实是基于租约的，从当前时间开始的T时间内我们尽量同步到sync_value，T时间后我们一定同步到sync_value。
性能优化
优化1.0
调大自增列段长度
增加预取机制。只要自增值段使用超过阈值，就尝试去获取一个新的段
调大租约时间
1，2降低了同步sync_value的概率，3降低了同步sync_value的频率。这三个优化能大大降低并发插入时由于网络抖动带来的性能问题。
优化2.0
测试情况看，优化1.0已经能应付90%以上的场景，但还不够。最明显的，抛开RPC主动通知，节点主动刷sync_value的动作总是等到租约到期才去做, 若这个时候线程hang住，其它请求就全部卡住了。
参考预取机制，OCeanBase继续做了优化，不等到租约到期，等超过租约一半时间就尝试同步sync_value，成功就续约，请求在租约内发生网络拥堵，其它请求可以继续使用缓存中的值，不会阻塞insert完成。
小结
本文主要简介OceanBase1.0自增列的实现细节，其实这里面还有很多兼容方面的细节没有介绍，比如insert on duplicate key自增列怎么处理？插入出错自增列怎么处理？感兴趣的继续可以讨论。
