Mysql PK 和 FK char(36) 与 int(10)答案

【问题标题】：Mysql PK and FK char(36) vs int(10)Mysql PK 和 FK char(36) 与 int(10)
【发布时间】：2011-07-02 17:45:37
【问题描述】：

我读到如果表键是整数而不是 char(36) UUID，mysql 可以更好地处理索引和搜索。

是否值得转换为 int(10)？

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

提前致谢。

【问题讨论】：

【解决方案1】：

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

但是：CHAR(36) 和 INT(10) 远非相等，因为 INT(10) 比 CHAR(36) 小很多。我不知道，如果你需要这么多不同的键，但你应该记住这一点。

更新，完成最后一段： INT(10) 是 32 位，CHAR(36) 是 36 - ^Byte^（= 288 位）。这不仅意味着INT 占用的空间更少，还意味着CHAR(36) 具有大约4 倍的不同键。

【讨论】：

【解决方案2】：

UUID 是已经建立索引的行，但众所周知，字符键比数字键慢，因为索引大小。

但如果您需要 UUID 或字符连接/索引，则必须考虑到这一点：

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

【讨论】：

【解决方案3】：

InnoDB 有很大的不同。如果您在表上定义 PRIMARY KEY，InnoDB 会将其用作聚集索引。

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

【讨论】：