mysql的uuid替代_替换MySQL的UUID版本1功能？

欣赏“类似部分”实际上是一个相当不错的主意。它将允许您利用MAC地址来识别“我的哪个服务器生成了此UUID？”......这在远程位置之间迁移数据时非常有用。您甚至可以这样做“这是我的测试数据”和“这是我的生产数据”。

PHP有大量的UUID生成器库。

这是PECL / PEAR的一件事(我从未使用过它)：

来自CakePHP框架：

最后一个生成器选项：

考虑使用Linux命令行uuid程序，该程序具有-v版本控制标志和相关选项，并使用它来提供数据库。这样效率很低，但至少你不必编写自己的生成器函数。

(Debian包uuid)

我注意到，对于命名空间版本，您将生成大量“长人名”以转换为uuids。只要你没有与那些冲突，它可能会非常甜蜜。例如，用户使用电子邮件地址注册...获取该电子邮件地址的v5 uuid ...您将始终找到该人！它似乎每次吐出相同的UUID，UUID将代表bob@bob.com与example.com作为成员的独特关系。

uuid -v5 ns:URL "http://example.com/member/bob@bob.com/"

评论：

此外，UUID，你似乎存储它们的方式，是CHAR(36)？一旦比较运营商开始，你可能会后悔。

Postgres将UUID视为128位值(并且可能是优化的二进制操作)，而MYSQL的CHAR(36)解决方案是查看36字节= 288位ANSI或576位UTF8加或减位/用于保持办公的字节(并且可能会执行更慢的multibyte-char-by-multibyte-char字符串例程)。

我实际上已经考虑了MySQL和UUID的问题......我的结论是你想要编写一个存储函数，将十六进制表示转换为二进制表示以便存储，以及这将使所有“选择”语句需要转换回十六进制表示...谁知道任何这些将是多么有效...所以最后切换到Postgres。 XD

如果您确实要切换到Postgres，请尝试在现有服务器(如果它们是生产服务器)上安装它时要非常小心。如...在实际执行迁移之前制作克隆以测试迁移过程。我以某种方式设法杀死我的系统，因为“安装此软件包将删除大量重要的其他软件包”(我不知道安装程序是如何做出这些决定的。)

或者，如果您准备最终为他们支付大量资金来操作数据库，请使用Microsoft SQL作为他们的GUID等价物......

目前做UUID和MySQL只是一个坏主意。