GUID 有哪些好的解决方案？答案

【问题标题】：What are the good solutions for GUID?GUID 有哪些好的解决方案？
【发布时间】：2012-06-07 12:44:38
【问题描述】：

目前，我有一个包含 1300 万行的数据库，我们使用 uuid 作为主键。每次我们进行数据库迁移时，完成一个表需要几个小时。查询性能似乎也很差。

在谷歌搜索和阅读一些博客后，他们建议将uuid 转换为binary(16)，但转换后的值不可读且使用起来非常尴尬。它也很难在我的 Ruby 代码中使用。

除了uuid之外，还有其他解决方案可以在 MySQL 中获取全局唯一标识符吗？

mysql> select UNHEX(REPLACE('A4E7890F-A188-4663-89EB-176D94DF6774','-',''));
+---------------------------------------------------------------+
| UNHEX(REPLACE('A4E7890F-A188-4663-89EB-176D94DF6774','-','')) |
+---------------------------------------------------------------+
| ���Fc��m��gt                                                       |

我查了一下，mongodb也有ObjectId，只有12个字节。是否可以在 MySQL 服务器中使用它？我如何利用它在 MySQL 中使用？

【问题讨论】：

我建议先把你的大桌子分成几张小桌子。这将有助于以很少的代码复杂性为代价进行迁移。
这是一个包含 200 个门户的数据库，该表是为这些门户准备的。如果我拆分，我应该拆分为 200 个数据库。这意味着我需要进行大量维护。
为什么是 200 个数据库？您可以将它们分组并创建，例如，10-20 个表（数据库）
每个表属于所有表。如果需要拆分，将它们全部拆分好吗？
是的，但是迁移速度更快。而且您始终可以继续拆分（并将数据移动到另一台机器）。混用数据格式的影响要小得多。

标签： mysql ruby ruby-on-rails-3 mongodb

【解决方案1】：

回答

您必须针对您的应用程序对此进行测试，但是对于非常大的数据集，如果您满足以下条件，我希望性能会有所提高：

使用 AUTO_INCREMENT 列作为主键，因为 MySQL 已针对此进行了优化。
索引您的 UUID 列，这样您就可以在不进行全表扫描的情况下进行快速查找。

比较冗长的 UUID 不可能像整数键一样有效，因此即使您仍在大量使用 UUID 列，也绝对应该通过这种方式获得性能提升。不过，没有什么可以替代您自己进行基准测试。

回答

相关问题