UUID做主键，好还是不好？这是个问题。

阅读更多

查看文章

UUID做主键，好还是不好？这是个问题。

2007年11月05日 星期一 下午 07:00

作者：老王 我唯一还算熟悉的数据库就算是MySQL了，大概使用MySQL的人，百分之九九以上的人会使用Autoincrement ID做主键，这是可以理解的，因为MySQL的自增ID效率很高，使用也很方便。那么剩下的百分之一的人使用什么做主键呢？可能是自己做的KeyGenerator，也可能是我们下面要说的UUID。 据说在Oracle的圈子里，如果谁用自增ID做主键是要被鄙视的，主键最自然的选择就是UUID。我不了解Oracle，这些道听途说的结论是否正确不做承诺。 那么我们先看看什么是UUID？简单的说，UUID是指在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的。在UUID的算法中，可能会用到诸如网卡MAC地址，IP，主机名，进程ID等信息以保证其独立性。 如果你的MySQL版本不太老的话，键入 SELECT UUID(); 输出的就是UUID，如下： mysql> select uuid(); +--------------------------------------+ | uuid()                               | +--------------------------------------+ | 54b4c01f-dce0-102a-a4e0-462c07a00c5e | +--------------------------------------+ 现在大家应该对UUID有一个比较直观的认识了，我们来看看UUID的优缺点分别是什么。 优点： 能够保证独立性，程序可以在不同的数据库间迁移，效果不受影响。 保证生成的ID不仅是表独立的，而且是库独立的，这点在你想切分数据库的时候尤为重要。 缺点： 比较占地方，和INT类型相比，存储一个UUID要花费更多的空间。 使用UUID后，URL显得冗长，不够友好。 下面针对上述UUID的缺点说说我的看法，比较占地方这个缺点我不是很在乎，现在最不值钱的就是硬盘了，略过此条缺点无妨。至于说使用UUID后，URL显得不友好，我觉得这多少是你的INT情结造成的惯性思维，其实，和INT类型相比，UUID才是最自然的主键选择，注意，我这里用的是自然这个形容词，仔细体会一下你能理解我的意思。另外，很多时候，URL本身就不需要友好，比如，一个电子商务网站，按照INT友好的URL说法，她的订单URL大概是下面这个形式的：/order.php/id/123，我要说明的是，这样是很友好，但是有些太友好了，友好的甚至不安全，比如说，我早晨下一个订单，发现URL是/order.php/id/1000，晚上再下一个订单发现URL是/order.php/id/2000，那么我就可以估计出此网站一天的订单数大致是1000左右，甚至能大体估计出它的销售额，而这些数据往往都是重要的商业秘密。使用UUID就没有这个顾虑。 效率？ 如果上面说的UUID的所谓缺点都不成立的话，那么是否使用UUID做主键，唯一的问题就是效率了。据说在PostgreSQL等数据库里，都有专门的UUID类型，在这样的数据库里，使用UUID做主键，效率没有任何问题，可惜在MySQL里没有这样的字段，如果想在MySQL里保存UUID做主键，一般是使用CHAR(36)来模拟，因为不是一个原生的UUID类型，所以主键的效率到底如何有待测试，另外，UUID做主键的效率和UUID本身的算法实现也有很大关系。 我本来想在我自己的电脑上插入1000000条数据测试一下看看来着，可惜一测试，硬盘灯就一直亮，让我很担心它会挂，虽然硬盘不值钱，但是我重要的数据都在上面，一旦坏了，损失就大了，所以，测试只好作罢。 至于在MySQL上使用UUID（用char(36)存储）做主键，效率到底如何，我也不知道，抱歉 -_-!!! 参考链接 （ 一）（ 二）（ 三）（ 四）（ 五）

类别：*mysql |  添加到搜藏 | 浏览( 2441) |  评论 (11)

 

上一篇： CakePHP里如何实现每个用户管理...    下一篇： Ruby的对象模型

 

最近读者：

	登录后，您就出现在这里。
		kelvin_zhou	cnraogang	chunchong	hbzhong85	ysongcn	sdzxx2008	no9988	nike_liu

 

网友评论：

1

网友: Jake

2007年11月05日 星期一 下午 08:52 uuid是字符串，不能用$id = intval($id)保证传回的是整数了。

 

2

网友: Jake

2007年11月05日 星期一 下午 08:53 会不会有SQL注入的危险。

 

3

网友: 老王

2007年11月06日 星期二 上午 11:40 to Jake: -_-!!!

 

4

网友: trooman

2007年11月06日 星期二 下午 01:55 uuid看起来的确是字符串型，怎么也没法想象它比整型的效率高！！做HASH时，大都选择整型，很多情况都说明用整型的效率比字符串类型高效啊！如果是订单，为了防止商业秘密泄漏，再加个订单编号不就行了？ 可能怪我认识浅陋！

 

5

网友: dualface

2007年11月06日 星期二 下午 04:12 用整型不代表就得顺序增加啊。比如订单号，完全可以按照日期或者其他规则来生成。反正int肯定足够存储的。

 

6

网友: dualface

2007年11月06日 星期二 下午 04:19 而且如果是垂直分割数据表的数据，将其分散到多个服务器存储。貌似int还更方便。比如有4台服务器，就可以用 $db_index = $id % 4 算出该记录放在哪个服务器。

 

8

网友: Jake

2007年11月08日 星期四 上午 05:13 to 老王 : P Just a little reminder.

 

9

星月浪子

2007年11月23日 星期五 下午 12:55 担心的uuid确实就是效率问题 需要大规模查询场合uuid没法和int比

 

10

redlz2500

2007年11月29日 星期四 上午 09:09 学习了

 

11

匿名网友

2007年11月29日 星期四 下午 03:37 http://hi.baidu.com/dandankai/blog/item/313eaf0a7dbd7a3db0351d4c.html http://www.zhenhua.org/article.asp?id=200

 

12

匿名网友

2007年12月19日 星期三 下午 12:52 http://dev.mysql.com/tech-resources/articles/