关于数据ID（2010-02-04）

去年搞LAMP时，想过一个问题：关于数据库中数据ID选择UUID（或者类似UUID的GUID等），还是自增型（整数类型）？其实搞毕业设计时就想过了，但是那时受实习公司的影响，采用了UUID而放弃自增型。后来发现其实采用自增型ID也有其好处。

UUID是指在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的。UUID按照开放软件基金会（OSF）制定的标准计算，用到了以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字。其主要由以下几部分的组合：当前日期和时间（UUID的第一个部分与时间有关，如果你在生成一个UUID之后，过几秒又生成一个UUID，则第一个部分不同，其余相同），时钟序列和全局唯一的IEEE机器识别号（如果有网卡，从网卡获得其MAC码，没有网卡以其他方式获得）。UUID的唯一缺陷在于生成的结果串会比较长。关于UUID这个标准使用最普遍的是微软的GUID（Globals Unique Identifiers）。（摘自本人毕业设计，其它参考：维基百科、《UUID做主键，好还是不好？这是个问题。》）

自增型ID（Autoincrement ID），从字面可以理解，自动增加的整数。

两者比较，UUID的优点是方便数据迁移、数据库集群等，缺点是占的空间比自增型ID大很多，查询效率可能比较低。自增型ID的优点是查询快、方便排序，缺点明显是不能保证数据库间ID的唯一性。

空间的问题，正如我同事经常说的，现在硬盘不值钱，存储空间不用考虑。相信银行的系统也不会随便仅仅挂个500GB的硬盘上去。

性能的问题，网上有人说拿200万条数据做测试对比，发现UUID的查询效率落后于自增型ID一个数量级。虽然随着CPU的发展，计算机的性能不能提升，但是对于大型数据库系统来说，效率很重要！没做过对比，我也不好说。

唯一性的问题，如果用自增型ID，做数据迁移或数据库集群时，就会带来灾难性的问题！有人说可以通过修改ID来解决，但数据关联都用到ID，ID一修改，关联就没了。如果约定自增型ID在不同数据库中的范围不同，是可以在一定程度上解决问题的，但数据一旦超出预计范围，那还是没解决问题。UUID就灵活多了，但网上有人说居然发现有UUID重复的情况，难以置信！

感觉对于我们开发的中小系统来说，还是UUID比较适合，毕竟数据量还不算庞大。