迁移现有表以使用 INT 主键而不是 UUID mysql v8

Question

我很想听听大家对这个问题的看法。我目前在 RDS 中使用 Innodb mysql v8。我们的数据库中等，有大约 130 个表，大多数都很小，最大的表在 6 年内有大约 3000 万行。目前，我们已经将 RDS 即时垂直扩展得比我们的数据库需要的要大得多，但我们仍然受到 CPU 限制，并且无法使用副本，因为从属设备落后太多了。我确信这是因为我们将 UUID 版本 1 作为表的主键，并且必须为我们的应用程序进行大量字符串比较。

我想做的是通过创建使用自动递增 INT 作为主键和外键的表子集来证明这一点，但我正在努力了解这是如何工作的。如果我只是向当前表添加一个自动递增列，我们的 ORM 使用的查询将不会包含它，因此不会有太大的收益。我想知道如何使用转换表将值从 UUID 交换到 INT。例如，ORM 查询现在的内容如下：

select id_primary_key from table_old where id_foreign_key in (UUID1, UUID2, UUID3) ，输出为：1d3sed4a-5812-a35c-0204-515f6at42b46

如果我创建一个包含 auto_inc INT 和旧 UUID 的转换表，那么下一步是什么，以便当 ORM 运行该查询时，它针对 INT 而不是 UUID 进行查询？

select id_primary_key from table_new where id_foreign_key in (1, 2, 3) 输出：58743

有什么想法吗？

更新——看来我们将来会研究更多的全局模型，其中有多个数据库，因此将保留 UUID。我们将尝试走分片路线，并尝试将它们存储为 VARBINARY(16) 并使用 UUIDtoBIN() 并将交换标志设置为 true，因为我们使用的是 UUID v1。感谢大家的回答和时间！我从测试中学到了很多东西。

Answer 1

从 UUID 更改为整数势必需要大量工作来实现，而且可能没有帮助。我建议在进行侵入性更改之前首先尝试更具体地了解为什么会出现性能问题。

例如：

• 您是否使用基于 ROW 的复制并且拥有没有主键约束的大型表？副本将为该表上的每个更新执行表扫描，这会降低复制吞吐量。

• 插入/更新/删除的速率是否太高以至于复制无法跟上？或者副本是否被配置为性能低于源服务器的服务器？或者您是否需要将数据库拆分为“分片”，以便每个分片都有一小部分写入流量？

• 您是否已识别出慢速查询并使用 EXPLAIN 来分析其优化？有多少人进行表扫描或索引扫描而不是使用索引来改进搜索或排序？您是否有合适的索引来帮助这些查询？在比较字符串、使用 LIKE 或 REGEXP 或在不创建表达式索引的情况下比较表达式结果时，查找常见错误，例如排序规则不匹配。

无论如何，在针对生产系统实施该解决方案之前，您应该开发一些测试来证明该解决方案能够解决您的问题。

Answer 2

我创建了一个包含 auto_inc INT 和旧 UUID 的转换表，下一步是什么，以便当 ORM 运行该查询时，它针对 INT 而不是 UUID 进行查询？

好吧，您想要连接到该转换表，当您拥有该转换表时，该转换表将由新INT字段连接，但不幸的是，UUID当您没有该转换表时，例如当您尝试将父表和子表连接在一起时，该转换表将由新字段连接。

我认为从长远来看，这种方法可能需要更多的维护工作，并且如果您的问题确实是由于使用UUID.

相反，为什么不只是：

1. 向每个表添加INT AUTO_INCREMENT具有适当起始值的新主键列（以及INT适用的外键列）。
2. ROW_NUMBER()根据您认为合适的任何排序逻辑，使用窗口函数（例如 ）回填该列。
3. 通过当前字段将所有外键相关的子表与其父表连接起来UUID以将它们关联起来。
4. 在上述连接之后，INT使用其相关父表的INT新主键值更新新的外键字段。
5. 从每个表中删除旧UUID列。
6. 将新列重命名为旧列名称。

这肯定会是大量的前期工作，但我认为从长远来看，与替代方法相比是值得的，并且将确保您完全依赖于字段INT，从而确保在这方面的最佳性能。