如果将主键设置为INT
type(AUTO_INCREMENT
)或将其设置为in UUID
,则两者在数据库性能(SELECT
,INSERT
等等)之间有什么区别,为什么?
UUID
返回一个通用的唯一标识符(如果导入到另一个数据库,希望也是唯一的)。
引用MySQL文档(重点是我的话):
UUID被设计为在空间和时间上全局唯一的数字。即使对两个未相互连接的单独计算机执行了对UUID()的两次调用,它们也会产生两个不同的值。
另一方面,简单的INT
主ID密钥(例如AUTO_INCREMENT)将为特定的DB和DB表返回一个唯一的整数,但不是通用的(因此,如果导入到另一个DB,则可能会有主键冲突)。
在性能方面,使用auto-increment
over不应有任何明显的区别UUID
。多数帖子(包括本网站作者的一些帖子)都这样声明。当然,UUID
可能要花费更多的时间(和空间),但是对于大多数(如果不是全部)情况,这并不是性能瓶颈。拥有一列Primary Key
应该使两个选择等同于性能。请参阅以下参考:
UUID
还是不去UUID
?GUID
与Autoincrement
UUID
vs auto-increment
cakephp-mysql中UUID
MySQL的性能?ID
s与GUID
s(编码恐怖)(UUID
vsauto-increment
性能结果,取自神话,GUID
vsAutoincrement
)
GUID
优点
- 在每个表,每个数据库,每个服务器中都是唯一的
- 允许轻松合并来自不同数据库的记录
- 允许在多个服务器之间轻松分发数据库
- 您可以
ID
在任何地方生成,而不必往返于数据库- 大多数复制方案
GUID
仍然需要列
GUID
缺点
- 它比传统的4字节索引值大4倍;如果您不小心,可能会对性能和存储造成严重影响
- 调试麻烦(
where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}'
)- 生成的
GUID
s应该是部分顺序的,以实现最佳性能(例如,newsequentialid()
在SQL 2005上),并允许使用聚簇索引。
我会仔细阅读提到的参考资料,并UUID
根据我的用例决定是否使用。也就是说,在很多情况下,UUID
s确实是更好的选择。例如,可以完全UUID
不使用/访问数据库的情况下生成,甚至可以使用UUID
已预先计算和/或存储在其他地方的。另外,您可以轻松地概括/更新数据库架构和/或群集方案,而不必担心数据ID
中断和引发冲突。
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句