主键生成策略

应用开发中，我们经常需要涉及到数据主键的生成。大部分情况，我们会采用数据库主键自增，比如学生表，让学生表里的id自增。但是如果我们希望主键里保护日期信息呢？或者我们在库里实行了分表策略，表主键自增也是不行的。

有人会想到uuid，uuid能做到全局唯一的，能解决分表策略的问题，当时在主键里加入其他信息还是不行。还有个问题uuid字符串比较长，存储费空间，不方便建索引。

我之前采用的一个策略是建立一个专门的主键表，里面包含两个字段（id, tablename) .

sql如下：

CREATE TABLE `id_temp` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `table_name` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `table_name` (`table_name`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

生成id：

REPLACE INTO id_temp (table_name) value("tablename") ;
SELECT LAST_INSERT_ID() ;

如果我们业务表不介意id的连续性，可以多个业务表使用一个主键表。如果业务表要求id的连续性，那一个业务表得使用一个主键表。

如果需要主键中加入日期元素，需要使用当前日期加上上面方式生成的id就成了。

但是，当业务并发很大，这种生成速度已经满足不了需求时，怎么办呢？

以前支付宝红包刚出来的时候，记得发红包的人，生成红包后，会产生一个数字，其他人通过这个数字抢红包。假设某个关键时间点，大量用户在那个时间点生成红包，那这些数字怎么生成呢（这些数字必须得有唯一性）。

记得之前在一篇博客介绍过一个方案，地址忘记了，介绍的是Fickr使用的一种主键生成方案。他的方案和上面的类似，不过是一个分布式版。

选择N个数据库服务器，每台数据库建一个主键表，也是两个字段（id, tablename）。

不同的是，第一台数据库的建表语句是：

CREATE TABLE `id_temp` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `table_name` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `table_name` (`table_name`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

第m台建表语句是：

CREATE TABLE `id_temp` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `table_name` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `table_name` (`table_name`)
) ENGINE=InnoDB AUTO_INCREMENT=m DEFAULT CHARSET=utf8;

m是 1 到 N中间的一个数字，每台数据库主键的初始值不同，从1到N。

然后，每台数据库设置他们的 auto_increment_increment值，

set @@session.auto_increment_increment=N ;

大概意思我们应该明白了，1到N台服务器，每台服务器的自增初始值不同，分别从1到N，然后每次自增的长度是N。应用服务器分布式调用到不同的数据库后，都能保证id的唯一性，和单台数据库的效果是一样的，而且使用上数据库集群，解决了高并发的问题。

这里在引申一下，假如需要添加服务器，或者下线服务器，怎么办呢？

方案一：

我们可以假设在这个上线、下线数据库改动期间，id能自增到的最大值M（通过平时的统计，可以有更多的富余），取一个稍微大于M的一个值，记作K。然后每台数据库，重新设置他的 auto_increment_increment和auto_increment_offset值。第一台auto_increment_offset值设为K，第二台设为K+1，依次第m台设为K+m；每台的auto_increment_increment值设置为新的服务器数。

方案二：

先生成足够的id在缓存中，后面的请求不走db，全部从缓存取。然后修改每台数据库的auto_increment_increment和auto_increment_offset值，参数修改完后，在恢复从db取。