MySQL中的UUID性能？
我们正在考虑将UUID值用作MySQL数据库的主键。所插入的数据是从数十台，数百台甚至数千台远程计算机生成的，并且以每秒100-40,000次插入的速度插入，我们将永远不会进行任何更新。
在我们开始选择数据之前，数据库本身通常会获得大约5000万条记录，因此不是庞大的数据库，但也不小。我们也计划在InnoDB上运行，但是如果我们有更好的引擎来进行我们的工作，我们愿意改变它。
我们已经准备好使用Java的Type 4
UUID，但是在测试中已经看到了一些奇怪的行为。首先，我们将其存储为varchar（36），我现在意识到使用Binary（16）会更好-
尽管我不确定有多少更好。
更大的问题是：当我们有50M条记录时，此随机数据对索引的破坏有多严重？如果我们使用例如类型1的UUID标记最左边的比特，会更好吗？还是我们应该完全放弃UUID并考虑使用auto_increment主键？
当将不同类型的UUID作为索引/主键存储在MySQL中时，我正在寻找有关不同类型的UUID的性能的一般想法/提示。谢谢！
问题答案：
UUID是通用唯一ID。这是您应该在此处考虑的普遍部分。
您 真的 需要ID通用吗？如果是这样，那么UUID可能是您唯一的选择。
我强烈建议如果您 确实 使用UUID，请将它们存储为数字而不是字符串。如果您有50M +记录，那么节省存储空间将提高您的性能（尽管我不能说多少）。
如果您的ID并不需要是唯一的，那么我认为仅使用auto_increment可以做得更好，这可以确保ID在表中是唯一的（因为值每次都会递增）
-
问题内容： 根据此处找到的功能，我正在使用PHP生成UUID 现在，我想将其存储在MySQL数据库中。存储UUID v4的最佳/最有效的MySQL字段格式是什么？ 我目前有varchar（256），但我可以肯定它比所需的要大得多。我已经找到了很多几乎可以回答的内容，但是对于它们所指的UUID形式，它们通常是模棱两可的，所以我要询问特定的格式。 问题答案： 将其存储起来，好像您希望完全适合它一样，或
-
问题内容： 这是将UUID（）生成的MySQL GUID / UUID转换为二进制文件（16）的最佳方法： 然后将其存储在BINARY（16）中 我应该知道以这种方式进行操作有什么影响？ 问题答案： 含义不多。它会稍微减慢查询速度，但是您几乎不会注意到它。 无论如何都存储为内部。 如果要将二进制文件加载到客户端中并在客户端进行解析，请注意，它可能具有除initial之外的其他字符串表示形式。 的函
-
最大ngram 36 在速度和内存方面，这会得到真正糟糕的加班吗？有没有更好的方法来部分搜索UUID？例如，我有7e222584-0818-49b0-875b-2774f4bf939b，我希望能够使用9b0搜索它
-
问题内容： 在MySQL中使用UUID作为主键有意义吗？ 除了手动查询的麻烦之外，使用UUID代替常规INT的利弊是什么？ 问题答案： UUID的主要缺点是，如果您想在以后引用该记录以供进一步使用，则必须事先创建它们（即：在相关的外键表中添加子记录）： 不会让您看到新的UUID值是什么，并且由于您没有使用常规的auto_incremented主键，因此无法使用它来检索它。您必须分两步进行：
-
本文向大家介绍Mysql中存储UUID去除横线的方法，包括了Mysql中存储UUID去除横线的方法的使用技巧和注意事项，需要的朋友参考一下 参考： http://stackoverflow.com/questions/412341/how-should-i-store-guid-in-mysql-tables 通常用UUID做唯一标识，需要在数据库中进行存储。 UUID的格式 数据库中直接存储UU
-
问题内容： 我想知道是否在MySQL查询中使用CASE … WHEN … THEN表达式 对性能有负面影响？ 而不是使用CASE表达式（例如，在UPDATE查询中）， 您始终可以在程序中用 php，python，perl，java等编写if语句来选择要发送的查询（例如，以伪代码） ）： 或侵入： （这里的c1只需要表明在两种情况下都发生了某些事情） 哪种方法具有更好的性能？ 性能损失是多少？ 问题