little 神
id生成器, 替代mysql自带的 auto_increment, 这个业务场景稍微严格点，用 redis 自增没数据库稳妥(一旦redis重启，很难保证不丢几秒的数据。而如果并发量又大，那可能好几百个id重复了)
无锁，也无需事务支持, 有锁的话性能怎么撑得住, 会出现多个 session 同时 update 的情况, 但是这个操作是原子性的，只要你能保证一个操作是原子性的。就不需要锁，也不需要事务
这个只是生成id。
至于 insert 记录失败，关这个 id 生成器什么事？
不用这个 id 跳过去就是了嘛。auto_increatment 不也是一样在 rollback 的时候不会恢复么， id 不一定必须要连续。
任何业务来问一个id，我给一个新的id + 1给业务，保证并发量再大，都不会给重复就可以了。至于业务用不用这个id，还是中断了还是别的怎么的都不关id生成器的事。低耦合。
分表除了表名的索引不同之外，表结构都是一样的，如果各表的‘ID'字段仍采用‘AUTO_INCREMENT'的方式的话，ID就不能唯确定一条记录了。 这时就需要一种处于各个分表之外的机制来生成ID，我们一般采用一张单独的数据表（不妨假设表名为‘ticket_mutex'）来保存这个ID，无论哪个分表有数据增加时，都是先到ticket_mutex表把ID值加1，然后取得ID值。 这个取ID的操作看似很复杂，所幸的是，MySQL提供了LAST_INSERT_ID机制，让我们能一步完成。
- 新建数据表ticket_mutex
CREATE TABLE ticket_mutex (
name varchar(32) NOT NULL PRIMARY KEY COMMENT '业务名称',
value bigint(20) UNSIGNED NOT NULL COMMENT 'ID值'
)Engine=InnoDB DEFAULT CHARSET=UTF8 COMMENT '保存分表ID表';
字段‘name'用来说明这个ID是哪个业务的，比如‘用户'的ID，我们可以定为‘USER'； 字段‘value'即该业务的ID值。
- 初始化业务和其ID值
INSERT INTO ticket_mutex(name, value) values('USER', 0),('POST', 0);
+------+-------+
| name | value |
+------+-------+
| POST | 0 |
| USER | 0 |
+------+-------+
我们初始化了2条记录，即有2个不同的业务，分别代表‘用户信息'和‘主题信息'，它们初始ID值均为‘0'；
-
获取分表唯一ID
这个时候就要利用MySQL提供的LAST_INSERT_ID()机制了。 在往用户表里新增一条数据时，获取‘用户ID'：
UPDATE ticket_mutex SET value=LAST_INSERT_ID(value+1) WHERE name='USER';
SELECT LAST_INSERT_ID();
+------------------+
| LAST_INSERT_ID() |
+------------------+
| 1 |
+------------------+
通过这条语句之后，我们得到结果为1，这个值就是我们所需要的值。再来查看数据记录，我们发现记录总数没有改变，但是‘用户'的ID已经为1了；
**从上可以看出，通过MySQL的LAST_INSERT_ID机制，我们可以保证在记录总数不增长的情况下，让业务ID在不断的增加，从而保证了分表ID的唯一性。 **
-
LAST_INSERT_ID说明
从名字可以看出，LAST_INSERT_ID即为最后插入的ID值，根据MySQL的官方手册说明，它有2种使用方法
一是不带参数：LAST_INSERT_ID()，这种方法和AUTO_INCREMENT属性一起使用，当往带有‘AUTO_INCREMENT'属性字段的表中新增记录时，LAST_INSERT_ID()即返回该字段的值
二是带有表达式：如上面介绍的LAST_INSERT_ID(value+1)，它返回的是表达式的值，即‘value+1'；
5.** 唯一性测试**
