今天有个技术群里面，突然有人冒出来说，他被MySQL坑了。据说是有个包含了auto_increment的表，放在事务里面操作，虽然事务回滚了，但是这个自增列自增后的值并没有回滚。
我掐指一算，多半是他自己建错了表引擎，然后还把锅扔给了mysql。于是一贯乐(xi)于(huan)助(da)人(lian)的我马上切到mysql，按照他的说法，做了下面的操作:
先建了一个表，引擎innodb，同时还有一个自增id。
然后，随便插入几条数据，再看看插入结果:
好了，打脸开始。
开启事务，插入，查看，回滚，查看。
再插入数据，看。
我勒个去，玩砸了，我脸好痛。
这一定是打开方式不对，是不是哪错了？可是，这不就是一个正常得不能再正常的操作吗，也就是说，这还真是个坑咯？
事出反常必有妖。通过各种找资料，我才明白其实自增列下一个自增的值是放在内存的，跟事务并没有关系，当然也不会回滚。这个值在服务器启动后会初始化一次，然后就只会增加不会减少了。
这么说的话，可以在一次事务回滚之后，看一下show create table，然后重启下mysql，然后再show create table，应该就能看出问题来。
首先，show一下
然后，重启mysql
接着，再回来show一下
果然，下一个auto_increment变回去了。说明查到的资料是靠谱的。
其实冷静下来想想，这个feature也不难理解，事务的回滚，回滚的其实是数据库写入的值，而对于下一个自增id的值这种东西，其实不算数据库写入值的一部分。我们只是想当然的认为它该回滚而已，但其实它不回退回去也不是一个违反了定义的事。
其实如果知道了这个实现方式之后，很多关于自增列的特性也就不难理解了。比如先插入再删除，自增id是不会回去的，但重启了服务端之后就可以了。
虽然整篇都在说自增id，但是实际在实践中，我更倾向于自己生成主键，而不是使用数据库的自增。使用数据库的自增id，其实就是偷了一个懒，想着防止主键重复，而且还能按顺序增加。但实际上，如果使用了自增id，所有插入数据的地方都必须要放在一个入口，很容易成为瓶颈。另一方面，使用自增id的数据，往往小id都是一些特殊的数据，可能是脏数据，也可能是很久远的数据。这些数据在现在的代码规则下会有什么表现，并没有人能说得清楚，搞不好就成为黑客攻击站点的突破口。最关键的是，这些id其实算是业务数据的一部分，但是却由数据服务来生成维护，增加了耦合。
不过技术没有绝对的优点或者缺点，只有相对的适合和不适合。也许这个feature在现在是个意料之外的麻烦，自增在大业务量下面是个可能的瓶颈，但它们也会有更合适的地方。我们也没必要带着感情来吐槽这个特性，熟记特性于胸，说不定能在某个时刻发现它们牛逼闪闪的用途。
