我有一个基于 InnoDB 的模式，大约有 100 个表，大多数使用 GUID/UUID 作为主键。我是在我并不真正了解 UUID PK 对磁盘 IO 和碎片的影响的时候开始的，但我希望在处理服务器集群时避免使用单个密钥分配器的好处。我们目前没有处理大量的行，但我们会（数亿），我想为此做好准备。
现在我更好地理解了 InnoDB 中的索引，特别是主键的集群性质，我可以看到我的 UUID 从 DISK IO 角度来看是可伸缩性的糟糕选择，但我不想因为服务器而停止使用它们聚类要求。
接受/推荐的解决方案似乎是 Autoincrement PK (INT|BIGINT) 与唯一索引 UUID 键的混合。我的意图是为ai_col每个表添加一个新的第一列并将其分配为新的 PK，我正在从以下位置排队：
http://dev.mysql.com/doc/refman/5.1/en/innodb-auto-increment-handling.html
然后，我将在我的 UUID 键上更新/重新创建一个新的“唯一”索引，并继续在我们的应用程序层中使用它们。
我的期望是，一旦完成，我基本上可以忽略ai_col和其他一切照常运行。InnoDB 将有一个相对较小的基于 int 的 PK，用于集群并附加到其他唯一索引。
问题 1：我是否正确假设在这个新场景中，我也可以吃蛋糕并吃掉它？
后续问题是关于较小的“关联”表，即只有两列，都是其他表的外键隐式连接它们。在这些情况下，我通常有两个索引，一个是唯一的两列索引，首先使用更频繁的列，然后是另一列上的第二个单索引。我知道这基本上是实际行数据的 2.5 倍，但它似乎确实有助于优化期间我们更复杂的查询，并且在较小的表上相对可接受。
这些关联表中的大多数将只是主表中记录数的一小部分，因为它们通常更具体，但是，在少数情况下，这些关联表的记录数是其外国父表的数倍，即可能数十亿.
问题 2：将数字 PK 也添加到这些表中是否是个好主意？我猜答案将类似于“Benchtest it”，但我只是在寻找有用的智慧块。
如果我显然误解了任何内容，或者您可以提供我可能没有考虑的见解，我也会非常感激！
非常感谢！
编辑：正如答案中所承诺的，我只是想跟进任何感兴趣的人......这个解决方案非常有效:) 读写性能全面提高，到目前为止，它已经测试了大约 60 亿个 i/o /月，不费吹灰之力。