对于关系数据库来说，设计每个表的第一步都会确定其主键，主键就是ID。在“常识”之中，int型的自增id，字符串类型的uuid，其他与业务相关的唯一键…都是我们作为主键的选择。
int也可以是Integer，自不必说，如果数据量特别大，可以使用BigInteger。
int和uuid的优缺点比较
int的好处
<b>一、对于插入效率问题，通常有2个观点。</b>
<b>1、通常情况下，在插入数据的时候，使用自增id作为主键，效率更高。</b>
因为插入随机值会写到索引的不同位置，会导致页分裂、磁盘的随机访问，对于聚簇存储引擎还会产生聚簇索引碎片。数据量越大，INSERT语句会更慢。
<b>2、高并发情况下，int类型造成的磁盘热点问题会拖慢速度</b>
但是在多线程下，UUID做聚集索引比自增列做聚集索引要快，因为插入的数据分散在磁盘各个位置，不会造成磁盘的“热点”，另外UUID的生成是随即的，而自增还是有一个顺序等待的，这一点也要考虑。
理论上来说，UUID的更适用适应高并发的环境。理由是如果id顺序递增，每创建一条记录都需要对表加一次锁，这在高并发环境下是很大的开销。在实际的性能测试中，并行插入时，它的插入性能随着数据量指数级减慢。
不过从 innodb 存储特性看，这种做法非常不可取，如果数据量很大，可能导致严重的性能问题，主要原因有：1. innodb 的非主键索引都将存一个主键，uuid 相比整数 id，索引大小增加很多；2. uuid 主键比较肯定比 整数慢，另外非主键索引查找最终还要引用一次主键查找；3. innodb 主键索引和数据存储位置相关（簇类索引），uuid 主键可能会引起数据位置频繁变动，严重影响性能。
<b>uuid的优势</b>
而UUID可以无痛支持对表进行水平划分，将数据分布存储在多台不同的机器上。只要机器可以无限扩展，插入性能就能够得到保证。
<b>二、对于查询来说，int的主键查询效率要高于uuid</b>
整数类型往往是主键类型最好的选择，因为效率最高并且可以使用数据库的自增主键（方便）。字符串类型相比整数类型肯定更消耗空间，而且会比整数类型操作慢。关于这个话题的解释建议看《高性能MySQL》第三版 P125。
解决方案
<b>a、同时适用uuid和id，以空间换效率</b>
使用自增id作为主键，以此来应对插入效率问题；采用uuid做逻辑id，拥有了逻辑主键的诸多好处，而且可以用来应对之后的水平分表。
<b>b、先把数据写入redis，然后再写入关系型数据库</b>
我们做过类似的处理，但不是UUID，是用redis产生id。因为我的程序需要高写入，所以先要生成内存中的缓存对象，然后再用异步程序进行处理。我不用UUID是因为会失去了时间顺序的排列，一些地方可以简单的根据id排序来得到时间序列。这在后端构造redis的zset时候有时候有很大的方便。
<b>c、新浪微博根据自己的业务实现的uuid算法</b>
新浪微博的主键采用的是自己设计的UUID算法。
http://www.infoq.com/cn/articles/online-data-migration-experience
<b>d、为支持app离线模式而使用了uuid</b>
为支持移动端离线模式-数据库采用 UUID 字段
<b>e、自己生成绝对不会冲突的纯数字递增主键</b>
uuid的问题是：
1、纯字符串类型，算上连字符'-'的话，36个字符。而整数类型最大bigint也就8个字节。
2、对 innodb存储引擎来说，主键作为聚集索引，有序地插入（递增）比无序插入性能要好。而uuid 并不是有序的。
所以解决办法是，自己生成绝对不会冲突的纯数字递增主键。 Instagram 的做法同样适用于 mysql，见
http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram
<b>结论：</b>
具体业务具体讨论，方案也应该以适应自身业务为主。
