MySQL 中的 UUDI/GUID 主键答案

【问题标题】：UUDI/GUID primary key in MySQLMySQL 中的 UUDI/GUID 主键
【发布时间】：2017-09-01 08:11:52
【问题描述】：

我们有一个应用程序（IONIC 2 手机应用程序前端，ASP .Net Core 2.0 Web Api 后端和 MySql Server）。

手机应用需要能够在离线模式下工作，并且能够在有互联网连接时同步（上下）。我立即意识到 MySql 数据库中的自增 int 主键将是一个问题，并考虑改用 GUID/UUID 主键。但我担心性能。我有两个问题：

在 MySql 中存储 UUID 字段的最佳方式是什么？字符（36）？据我所知，MySql 没有专用的 UUID 数据类型？（我使用的是 MySql Server 5.6.30）
不将其设为主键是否是个好主意，这样它就不是唯一的了？这肯定会加快性能吗？而且 UUID 几乎可以保证是唯一的，所以 MySql Server 没有必要浪费时间检查这个......

谢谢

【问题讨论】：

我不理解这个问题，也不知道您为什么要在 UUID 或自动增量主键之间进行选择。当应用程序最终上线并进行同步时，只允许 MySQL 分配一个 id 会有什么问题？
感谢蒂姆的快速回复。好吧，手机应用程序将有一个本地数据库，它们将在离线模式下存储所有数据。如果我们使用自动递增的 int 主键，并且手机应用程序的用户创建了一条新记录，它可能会得到 ID = 157（这将用于具有该表的外键的所有其他表）。现在，当手机在线并且应用程序同步时，在实时数据库上它可能会获得不同的 ID（因为其他用户同时同步了他们的新记录）。现在手机数据库和实时数据库上的 ID 不匹配
是的，当手机应用程序同步时，Web API 可以告诉手机应用程序实际 ID 是什么，然后手机应用程序可以更新它在所有表格中的 ID。但这可能是 Web API 告诉手机应用程序“正确，该记录的实际 ID 是 160”的问题，但手机应用程序已经使用了该 ID（因为他们在离线工作时添加了 4 条新记录）
我想我没有看到拥有两个 ID 的问题。主数据库使用自动增量，每个应用程序都有自己的 ID。从其他应用程序的角度来看，这没有错；那些其他应用程序无论如何都无法在主目录中看到新项目。
hmmm.... 好的，所以客户端 ID 和主 ID 之间会有某种映射？

【解决方案1】：

如果没有完整的详细信息，我会建议以下一般工作流程：

这里的基本思想是只关注尽可能多地保留一个版本的真相。不要让您的应用程序为服务器一无所知的产品分配 ID。一方面，分配这样一个 ID，然后用户决定删除产品而不进行同步是否有意义？

【讨论】：

感谢蒂姆的回复。好的，我知道你来自哪里，这是有道理的。我只有一个问题。当应用程序同步时，将新记录推送到主数据库（通过 Web API）应该没问题。但是推动对现有记录的编辑呢？ Web API 如何知道在主数据库中编辑哪条记录？反之亦然，如果在主数据库中编辑了一条记录，那么应用程序在执行同步时如何知道在其本地数据库中更新哪个对应的记录？谢谢蒂姆，感谢您的意见。
好的，我意识到我可能遗漏了一些东西...每次应用同步时，两个数据库应该是相同的，所以编辑记录应该没问题...
您的应用告诉数据库要更新哪些记录，就像告诉数据库要插入哪些新记录一样。就通过 JSON 获取产品目录之类的操作而言，您的应用只需下载整个内容，或者如果您设置了一些分页，那么它会请求某个页面。
等等...您是否要在 SQLite 表上镜像服务器 MySQL 表？好吧，我的建议是不要。为同步结果保留一个 SQLite 表，另一个用于存储新产品添加。
啊哈.....好吧，我从没想过这样做......让我考虑一下:)