我有一个基于InnoDB的架构，大约有100个表，大多数使用GUID / UUID作为主键。我是在一个时间点开始的，我没有真正理解UUID PK对磁盘IO和碎片的影响，但是想要在处理服务器集群时避免使用单个密钥分配器的好处。我们目前没有处理大量的行，但我们将（数亿）我想为此做好准备。
既然我更了解InnoDB中的索引，特别是主键的集群特性，我可以看到，从DISK IO的角度来看，我的UUID是可扩展性的不佳选择，但我不知道由于服务器群集要求，我们希望停止使用它们。
接受/推荐的解决方案似乎是Autoincrement PK（INT | BIGINT）和UNIQUE Indexed UUID键的混合。我的目的是为每个表添加一个新的第一列ai_col，并将其指定为新的PK，我将从以下队列中获取队列：
http://dev.mysql.com/doc/refman/5.1/en/innodb-auto-increment-handling.html
然后我会更新/重新创建一个新的＆＃34; UNIQUE＆＃34;我的UUID键上的索引，并继续在我们的应用程序层中使用它们。
我的期望是，一旦完成，我基本上可以忽略ai_col，其他一切照常运行。 InnoDB将有一个相对较小的基于int的PK，可以从中聚集并附加到其他唯一索引。
问题1：我是否正确地假设在这个新场景中，我可以吃蛋糕并吃掉它？
后续问题是关于较小的＆＃39;联盟＆＃39;表，即只有两列，两个表的外键都隐式连接它们。在这些情况下，我通常有两个索引，一个是UNIQUE两列索引，首先使用更多的列，然后是另一列的第二个单个索引。我知道这实际上是实际行数据的2.5倍，但它似乎真的有助于我们在优化期间更复杂的查询，并且在较小的表上是如此相对可接受。
这些关联表中的大多数只是主表中记录数的一小部分，因为它们通常更具体，但是，有少数情况下这些记录的数量是其外国的倍数父母，即潜在的数十亿。
问题2：将数字PK添加到这些表格中也是个好主意吗？我猜测答案将是＆＃34; Benchtest it＆＃34;但我只是在寻找有用的智慧。
如果我明显误解了任何内容，或者你可以提供我可能不会考虑的见解，我也非常感激！
非常感谢！
编辑：正如答案中所承诺的那样，我只是想跟进任何感兴趣的人...这个解决方案已经有了很大的作用:)读写性能全面提升，到目前为止它和＃39;经过多达60亿次i / o /月的测试，没有出汗。
答案 0 :(得分：1)
在没有任何其他建议，确认或其他情况下，我已经开始在我们的开发服务器上测试一些较少使用的表，但是如果新的基于AI的id会影响我们的应用程序那么会受到影响的表层。
到目前为止看起来很好，索引按预期执行，新表字段不需要对我们的应用程序层进行任何更改，我们基本上可以忽略它们。
我没有经过任何彻底的基准测试来测试重负载下的实际磁盘IO，但是从主题上的大量信息来看，我可以推测我们在扩展方面处于良好状态。 / p>
一旦这种情况发生了一段时间，我会跟进，以防万一我们在同一条船上。