innodb最为大家津津乐道的就是它实现了行锁等高级特性，相比之下，myisam的表锁显得有些弱智。不过很多人都忽视了一点，innodb在MySQL5.0里有时候的行为也是表锁：比如说当表里有一个auto_increment字段的时候，innodb会在内存里保存一个计数器用来记录auto_increment的值，当插入一个新行数据时，就会用一个表锁来锁住这个计数器，直到插入结束。如果一行一行的插入数据则没有什么问题，但是如果大量的并发插入就废了，表锁会引起SQL堵塞，不但影响效率，而且可能会瞬间达到max_connections而崩溃。
在MySQL5.0版本，只要使用了auto_increment字段，那么innodb的表锁问题就无法回避，如果你必须面对大量并发插入的情况，要么听天由命，要么便只能抛弃auto_increment，转而使用自定义主键的方式，但必须小心选择，否则可能会陷入到另一个陷阱当中，比如说，有的人会通过使用UUID主键的方式来回避auto_increment表锁的问题，但是这可能会让应用陷入更严重的IO瓶颈问题之中去，原因可以参考我以前写的文章：
还有一个方法就是使用MySQL5.1，在这个版本里，出现了一个新的配置选项：innodb_autoinc_lock_mode，它是专门用来在使用auto_increment的情况下调整锁策略的，目前有三种选择：
innodb_autoinc_lock_mode = 0 (“traditional” lock mode)
innodb_autoinc_lock_mode = 1 (“consecutive” lock mode)
innodb_autoinc_lock_mode = 2 (“interleaved” lock mode)
?
CakePHP本身有一个uuid实现，所以一直以来，我都在尝试使用uuid做主键的可能性。虽然MySQL是我最常用的数据库，但是和auto_increment_int主键相比，我对uuid主键更有好感，一方面是因为uuid的数据库无关性，另一方面是当你想把程序分布在多台服务器上时，uuid操作更简单。
不过MySQL还没有原生的uuid支持，在和innodb表类型配合时，可能会出现一些问题：
首先，innodb会对主键进行物理排序，这对auto_increment_int是个好消息，因为后一次插入的主键位置总是在最后。但是对uuid来说，这却是个坏消息，因为uuid是杂乱无章的，每次插入的主键位置是不确定的，可能在开头，也可能在中间，在进行主键物理排序的时候，势必会造成大量的IO操作影响效率。
幸运的是，CakePHP的uuid算法最开始那部分的字符串是基于时间戳的，所以单就CakePHP的uuid而言，不存在这个问题，如果是其他的uuid算法，这个问题一定要仔细考虑。
其次，因为其他的索引要和主键关联，当主键是uuid时，和int相比必然会占用更大的空间，在较大的空间上检索肯定比在较小的空间上检索耗时。
这个问题解决起来办法不多，比较常见的方式是主键仍然用auto_increment_int来做，而另加一个uuid做唯一索引，表外键关联什么的，还用uuid来做，也就是说auto_increment_int只是一个形式上的主键，而uuid才是事实上的主键，这样，一方面int主键不会浪费太多空间，另一方面，还可以继续使用uuid。
还有一个问题是在MySQL里使用uuid，一般是用char(36)来声明字段，如果列编码是gbk/utf8这样的复杂的编码，会拖累主键的效率，这时候，我们那字段编码转换成ascii/latin1这样的简单编码会好一些。
?
?
################################################
?
官方文档已经给出了很好的描述，就不多说了。需要提醒的是MySQL5.1现在还没有Stable，要谨慎使用。
?
innodb_autoinc_lock_mode 下自增id不连续的原因
一、问题复现
文件/tmp/data.sql中两列，每列一个数字1;
?
输入
|
CREATE TABLE `t` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `k` int(10) unsigned NOT NULL DEFAULT '0', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8; load data infile '/tmp/data.sql' into table t(k); show create table t; |
?
结果：
|
CREATE TABLE `t` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `k` int(10) unsigned NOT NULL DEFAULT '0', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 |
?
二、原因分析
我们知道在5.1.22在之后，InnoDB为了解决自增主键锁表的问题，引入了参数innodb_autoinc_lock_mode。这个值为0时，每次申请自增主键时需要锁表。
这个参数的默认值是1，设为此值时，每次会“预申请”多余的id(handler.cc: compute_next_insert_id)，而insert执行完成后，会特别将这些预留的id空出，动作就是特意将预申请后的当前最大id回写到表中(dict0dict.c:dict_table_autoinc_update_if_greater)。
?
三、简单计算预留
注意这个预留的策略是“不够时多申请几个”， 实际执行中是分步申请。至于申请几个，是由当时“已经插入了几条数据N”决定的。当auto_increment_offset＝1时，预申请的个数是 N-1。
所以会发现，当data.sql中只有一行时，你看不到这个现象，并不预申请。
而当有两行时（如文章开头的例子），则需要。多申请的数目为1，因此执行后的自增值为4 (1+2+1)。
若data.sql中有三行呢？由于执行第三行的id已经在执行第二行时预留了，所以直接使用，结果的自增值仍为4。
后续的就类推了，可自行分析下。
|
实际insert行 |
自增id增加值 |
|
2、3 |
3 |
|
4、5、6、7 |
7 |
|
8～15 |
15 |
