Mysql PK和FK char（36）vs int（10）

Question

我已经读过，如果表键是整数而不是char（36）UUID，那么mysql可以更好地处理索引和搜索。

是否值得转换为int（10）？

注意：我们只使用1台服务器，目前必须同时计划使用多个数据库，因此消除了使用UUID的一个重要原因。如果有所作为，我们的表也是InnoDB。

提前致谢。

Answer 1

通常RDBMS可以比其他数据类型更有效地处理Integer键。原因是它如何构建列的索引，所以是的：只要你不需要字符串（或其他类型）键，你应该总是使用整数。

然而：CHAR（36）和INT（10）远离相等，因为INT（10） 小于CHAR（36）。我不知道，如果你需要这么多不同的钥匙，但你应该牢记这一点。

更新，以完成最后一段： INT(10)是32位，CHAR(36)是36 - ^ Byte ^（= 288-Bit）。这不仅意味着，INT消耗的空间更少，也意味着CHAR(36)的密钥大约是其中的4倍。

Answer 2

UUID是一个已编入索引的行，但是众所周知，字符键比数字键慢，因为索引大小。

但是如果你需要一个UUID或角色加入/索引，你必须考虑到这一点：

1. 与整数键相比，CHAR键的连接速度确实较慢
2. Innodb表格的性能下降幅度可能从几个百分点到几倍
3. 如果未禁用密钥压缩，MyISAM表可能会受到严重影响
4. 加入Shorter CHAR键明显快于Long键
5. Latin1（我猜任何简单的编码）与UTF8相比，连接速度明显更快

我分享此信息并在生产环境中对其进行了测试，可以在http://forums.mysql.com/read.php?24,263462,263462

中找到

Answer 3

InnoDB带来了巨大的变化。 如果在表上定义PRIMARY KEY，InnoDB会将其用作聚簇索引。

在巨大的innodb表上进行DML操作非常昂贵。如果您有许多连接，请使用整数。如果你有很多dml使用int。如果你有比dml更多的选择使用自然键，无论是int还是char