MySQL中INT和UUID的区别

Question

如果我将主键设置为INT类型（AUTO_INCREMENT）或将其设置为UUID，那么这两者之间的区别是什么？数据库性能（SELECT，INSERT等）以及为什么？

Answer 1

UUID会返回universal unique identifier（如果导入到其他数据库，也希望也是唯一的。）

引用MySQL doc（强调我的）：

  

UUID被设计为在空间中具有全局唯一性的数字   时间即可。对UUID（）的两次调用预计会产生两种不同的调用   值，即使这些调用是在两台独立的计算机上执行   彼此没有联系。

另一方面，简单的INT主ID键（例如 AUTO_INCREMENT ）将为特定的DB和DB表返回唯一整数，但是不是普遍唯一的（因此，如果导入到其他数据库，则可能会出现主键冲突）。

就性能而言，使用auto-increment而不是UUID应该没有任何明显的差异。大多数帖子（包括本网站作者的一些帖子）都是这样说的。当然UUID可能需要更多的时间（和空间），但对于大多数（如果不是全部）情况而言，这不是性能瓶颈。将列作为Primary Key应该使两个选项与性能相等。见下面的参考文献：

1. To UUID or not to UUID?
2. Myths, GUID vs Autoincrement
3. Performance: UUID vs auto-increment in cakephp-mysql
4. UUID performance in MySQL?
5. Primary Keys: IDs versus GUIDs (coding horror)

（UUID vs auto-increment效果结果，改编自Myths, GUID vs Autoincrement）



UUID利弊（改编自Primary Keys: IDs versus GUIDs）

  

GUID优点

     

  
• 每个表，每个数据库，每个服务器都是唯一的
  
• 允许轻松合并来自不同数据库的记录
  
• 允许跨多个服务器轻松分发数据库
  
• 您可以在任何地方生成ID，而不必转发到数据库
  
• 大多数复制方案无论如何都需要GUID列
  

     

GUID缺点

     

  
• 比传统的4字节索引值大4倍;如果这可能会产生严重的性能和存储影响   你不小心
  
• 调试繁琐（where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}'）
  
• 生成的GUID应该是部分顺序的，以获得最佳性能（例如，SQL 2005上的newsequentialid()）并启用   聚集索引。
  




注意

我会仔细阅读上述引用，并根据我的用例决定是否使用UUID。也就是说，在许多情况下UUID确实更可取。例如，可以在不使用/访问数据库的情况下生成UUID，甚至可以使用已经预先计算和/或存储在其他地方的UUID。此外，您可以轻松地概括/更新数据库架构和/或群集方案，而无需担心ID破坏和导致冲突。

Answer 2

A UUID key cannot be pk until unless persisted in DB so round tripping will happen until then you cannot assume its pk without a successful transaction. Most of the UUID use time based, mac based, name based or some random uuid. Given we are moving heavily towards container based deployments and they have a pattern for starting sequence MAC addresses relying on mac addresses will not work. Time based is not going to guarantee as the assumption is systems are always in exact time sync which is not true sometimes as clocks will not follow the rules. GUID cannot guarantee that collision will never occur just that in given short period of time it will not occur but given enough time and systems running in parallel and proliferations of systems that guarantee will eventually fail. [http://www.ietf.org/rfc/rfc4122.txt].