主键选择选择自增还是序列？

   

首先申明一下是不同数据库的的设计不一样，有的有自增，有的有序列，怎么用？很多年前使用Oracle的时候我们做公安系统每过一辆车，甭管是机动车还是非机动车都记录，像上海这样的地方每天新增数据在1亿上下。300多万本地机动车再加一些非沪的外地机动车，不到400万。正常一辆私家车开出去，再开回来，经过10个路口或者路段很平常，那么就是说每天被记录20次。所以不到400万X20多次。大致在一亿左右。在全国各地情况也类似。

   那么如何存储这些数据，保证查询的时候高效？首先我们查询车辆都靠车牌，那么车牌必然是索引。但是我们车辆被拍照主要存储的还是照片。我们的照片没有存在数据库中（那样太大了，不过早期是存数据库的），那么这个时候主键和图片的名称要一一对应。这就对主键的唯一性要有要求了。如何保证高效而且不冲突。

   假设我们在江苏省安装了1万个设备从徐州到苏州（前提是我们接了一个全省的大活）。每个设备控制4-8个车道，几乎每秒都有1k-1w的设备（你可以想想成为物联网）在采集数据写入数据库。实际数据库的写入也是在每秒几百到几千这样的大致情况。

   我们当时采用的主键方式是行政区划+设备编号+车道+年月日时分秒。

   行政区划就是理解是邮编，我们邮寄信件在大陆6位编号可以区分到一个乡镇。

   设备编号，在一个乡镇级别能安装100个设备已经很饱和了。但是我们还是留了4位，可以安装9999个设备。即使北京天通苑这样的跨三个地铁站的小区，也够用了。每个行政区划的设备都从1开始编号。

   每个设备有1-16个车道。

   每个车道同一秒最多只能有一辆车。

  所以江苏省常州市天宁区的设备就是213000+1234+5+2022年6月1日10点01分30秒  即2130001234520220601100130这就是主键。我们一看这个号码也能知道这个数据来源于哪里。

可见我们没有用Oracle的序列。理由如下：

1、 取有序列竞争，我们每秒要处理几百几千。设计上就没有竞争，无需redis。一旦冲突就写入失败，车过了就过了，不可能重发一次。要求不能延迟，不能丢失。

2、 自然数没有含义，没实际用。

3、 遇到最大怎么办？演示一下

当取到a的最大就停止了，这个适合要人工介入继续改大，但是什么时候是个头？

如果采用循环复用请看下面。技术上可以，但是如果序列是主键那么就冲突了。

所以我们没有采用序列，不是序列不好，而是我们这样设计更好。所以单表几十亿上百亿都没有问题。

 

那么其他数据库也这样吗？我来看看PG的。语法和Oracle略有不同

 

create sequence a increment by  1 minvalue  1 maxvalue 5 start with  1;

create sequence b increment by  1 minvalue  1 maxvalue 5 start with  1 cycle;

 

实验效果和Oracle的是一模一样。

分别是到最大值停止。

 

和循环复用。

 

 

那遇到没有序列的怎么办？有些数据库没有序列但是有自增，比如MySQL。这里请不要提从redis中取（至少在我的业务流水中我永远不会这样设计），原因都说了，另外无意义的存与什么用？

那MySQL自增有什么用？因为Oracle是堆表，MySQL是聚集索引表，顺序存储最紧凑。那个id自增就是给你紧凑存储的。千万不要有业务含义，业务含义放到第二列中去建立唯一。前几天遇到有几个数据库要合并，这个时候体现出没听话的痛苦了。都拿自增的id有业务含义或者关联关系的。现在表数据要合并，大家互相排斥。伤脑筋。早听我的就好了。

那么这个自增ID怎么选？一般都是int，int和范围有关，和长度无关。举例tinyint只能存256个数据，如果带上负的就只有到127了。

所以这个到了127以后，不能加了，再增加还是127.还要继续就报主键冲突了。这种只能改类型了。

    那么兼容MySQL的Tidb上怎么处理的？

 

看这个结果有点像Oracle的序列达到最大值的样子。

    不同数据库，不同场景设计不一样。千万别用错了。