我们正在构建一个新的网络应用程序,它将在许多本地设备上具有离线 iPad/Android 应用程序版本,这将涉及插入新数据。因此,我们需要使用 UUID 以允许与主数据库进行必要的双向同步。为此,我们将 UUID 存储BINARY(16)
为主键。
我研究后了解到的问题是,非顺序主键插入所需的时间会随着时间的推移而增加,并且这些插入会导致碎片(如此处所回答)。这样做的好处AUTO_INCREMENT
是新行通常只会添加到表的末尾,因此不会遇到 UUID 的速度问题。
我的问题是使用AUTO_INCREMENT
列作为主键然后将 UUID 列作为非空唯一索引是否更好?据推测,这将具有顺序插入的速度优势,同时保留同步分布式数据库所需的必要 UUID。
我可以看到的一个问题是 UUID 需要用作其他表的参考(使用外键约束)(即附加到检查的问题列表,而检查又附加到站点,所有这些涉及插入,因此所有这些都需要 UUID)。从语义上讲,主键作为参考更有意义,但作为一个分布式系统,我们不能AUTO_INCREMENTS
用于这些。JOIN
对于这些引用(当然还有它们附带的 s )使用(非空)唯一索引而不是主键是否有缺点?
还可能值得注意的是,主(在线)数据库使用 MySQL(InnoDB),而分布式(离线)数据库使用 SQLite。
编辑:
考虑到将 UUID 作为主键可能会更好(因为它在语义上就是这样),如果我将 UUID 设置为主键并将AUTO_INCREMENT
列设置为非空唯一索引,我是否会获得顺序插入的好处? 还是只有在确定在哪里插入新行时相关的主键?