mysql - 使用 GUID/UUID 键优化 Innodb 表索引

Question

我有一个基于 InnoDB 的模式，其中包含大约 100 个表，大多数使用 GUID/UUID 作为主键。我开始这个的时候我并没有真正理解 UUID PK 在磁盘 IO 和碎片方面的含义，但希望在处理服务器集群时避免使用单个 key 分配器的好处。我们目前没有处理大量的行，但我们会(数以亿计)并且我想为此做好准备。

现在我更好地理解了 InnoDB 中的索引，特别是主键的集群性质，我可以看到我的 UUID 从磁盘 IO 的角度来看是一个糟糕的可伸缩性选择，但我不想停止使用它们，因为满足服务器集群需求。

接受/推荐的解决方案似乎是自动增量 PK (INT|BIGINT) 与唯一索引 UUID 键的混合。我的目的是向每个表添加一个新的第一列 ai_col 并将其分配为新的 PK，我从以下位置获取队列:

http://dev.mysql.com/doc/refman/5.1/en/innodb-auto-increment-handling.html

然后我会在我的 UUID 键上更新/重新创建一个新的“UNIQUE”索引，并继续在我们的应用程序层中使用它们。

我的期望是，一旦完成，我基本上可以忽略 ai_col，其他一切照常运行。 InnoDB 将有一个相对较小的基于 int 的 PK，从中聚集并附加到其他唯一索引。

问题 1:我假设在这个新场景中，我可以吃蛋糕，也可以吃蛋糕，这是否正确？

后续问题是关于较小的“关联”表，即只有两列，都是隐式连接它们的其他表的外键。在这些情况下，我通常有两个索引，一个是 UNIQUE 双列索引，首先是使用频率较高的列，然后是另一个列上的第二个单一索引。我知道这实际上是实际行数据的 2.5 倍，但它似乎确实有助于我们在优化期间进行更复杂的查询，并且在较小的表上因此相对可以接受。

这些关联表中的大多数只会是主表中记录数的一小部分，因为它们通常更具体，但是，在少数情况下，这些关联表的记录数是其外国父表的许多倍，即可能有数十亿。

问题 2:将数字 PK 也添加到这些表中是否是个好主意？我猜答案会类似于“Benchtest it”，但我只是在寻找有用的智慧。

如果我明显误解了任何内容，或者您​​可以提供我可能没有考虑的见解，我也将不胜感激!

非常感谢!

---

编辑:正如答案中所 promise 的，我只是想跟进任何感兴趣的人......这个解决方案非常有效:)读写性能全面提高，到目前为止它是经测试高达约 60 亿次输入/输出/月，毫不费力。

Answer 1

在没有任何其他建议、确认或其他方式的情况下，我已经开始在我们的开发服务器上测试一些较少使用的表，但如果新的基于 AI 的 id 将影响我们的应用程序，这些表仍然会受到影响层。

到目前为止它看起来不错，索引按预期执行并且新表字段不需要对我们的应用程序层进行任何更改，我们基本上可以忽略它们。

虽然我没有运行任何彻底的基准测试来测试重负载下的实际磁盘 IO，但从关于该主题的大量信息来看，我可以推测我们在扩展方面处于良好状态。

一旦这已经到位了一段时间，我将进行跟进，以防有人和我们在同一条船上。