mysql - 使用 UUID 时，是否也应该使用 AUTO_INCREMENT？

Question

我们正在构建一个新的网络应用程序，该应用程序将在许多本地设备上提供离线 iPad/Android 应用程序版本，这将涉及插入新数据。因此，我们需要使用 UUID 以允许与主数据库进行必要的双向同步。为此，我们将 UUID 存储为 BINARY(16) 主键。

我研究后了解到的问题是，非顺序主键插入所需的时间会随着时间的推移而增加，并且这些插入会导致碎片(如回答 here )。 AUTO_INCREMENT 的好处是新行通常只会添加到表的末尾，因此不会遇到 UUID 的速度问题。

我的问题是使用 AUTO_INCREMENT 列作为主键然后将 UUID 列作为非空唯一索引是否更好？据推测，这将具有顺序插入的速度优势，同时保留同步分布式数据库所需的必要 UUID。

我可以看到的一个问题是 UUID 需要用作其他表的引用(使用外键约束)(即附加到检查的问题列表，而检查又附加到站点，所有这些都涉及插入，因此所有这些都需要 UUID)。从语义上讲，主键作为引用更有意义，但作为分布式系统，我们不能使用 AUTO_INCREMENTS 来处理这些。对这些引用(当然还有随之而来的 JOIN)使用(非空)唯一索引而不是主键是否有缺点？

另外值得注意的是，主(在线)数据库使用 MySQL (InnoDB)，而分布式(离线)数据库使用 SQLite。

编辑:

考虑到将 UUID 作为主键可能会更好(因为它在语义上就是这样)，如果我将 UUID 设置为主键并且 AUTO_INCREMENT 列作为非空唯一索引？还是只有在确定在哪里插入新行时相关的主键？

Answer 1

使用自动增量作为主要加上一个 uuid 列是一个有效的模型，但您仍然需要解决自动增量带来的一些问题，这完全取决于您如何进行同步。

无论如何，我一直在使用 uuid 作为主键(我当前的数据库有 50 万条记录)并且它仍然非常快，它只会减慢插入速度，但除非您每天的插入量非常大它不应该吓到你。

如果你使用 Sql-Server，你可以看看另一个解决方案是 Sequential UUID，它比普通 UUID 的碰撞几率略大，但绝对碰撞几率仍然很低，因为它们是部分顺序的涵盖了碎片化的问题。