我在一个平台上工作，其中唯一用户 ID 是来自 Amazon Cognito 身份池的身份 ID。看起来像这样:“us-east-1:128d0a74-c82f-4553-916d-90053e4a8b0f”
该平台有一个 MySQL 数据库，其中包含用户可以查看的项目表。我需要添加一个收藏夹表来保存每个用户的每个收藏夹项目。该表可能会增长到数百万行。
“收藏夹”表的布局如下所示:
userID, itemID, dateAdded
其中 userID 和 itemID 一起是复合主键。
我的理解是，这种类型的 userID(实际上是扩展的 UUID，需要存储为 char 或 varchar)的索引性能很差。因此，不鼓励将其用作数百万行的键或索引。
我的问题是:我的理解是否正确，我是否应该因为这个 key 而担心以后的性能？我可以采取任何缓解措施来降低性能风险吗？
我的整体数据库知识不是很好，所以如果这是一个大问题...将收藏夹列表移动到 NoSQL 表(其中 userID 作为键将允许恒定的访问时间)，并检索数组最喜欢的项目 ID，用于 SELECT...WHERE IN 查询，是可接受的替代方案吗？
非常感谢!
最佳答案
好的，所以在这里我想说说为什么这不好，替代方案以及应用程序的读/写工作流。
为什么不:这不是一个好的架构，因为如果您的 Cognito 用户池出现问题，您无法为每个用户使用相同的 ID 重新填充它。此外，Cognito 现在正在更多地区提供；与去年相比。假设您的用户群在印度尼西亚，而现在 Cognito 在新加坡可用；您想将您的用户群从东京转移到新加坡；由于延迟问题；不仅您有移动用户的问题；您有填充数据库的问题；因此您的方法缺乏可扩展性、可维护性，并且违反了单一责任原则(更新 Cognito 需要您更新数据库，反之亦然)。
备选方案:将db索引留给db域；并使用 username 作为您的数据库和 Cognito 用户池之间的链接。所以:
阅读工作流程为:
用户身份验证:用户进行身份验证并获取 token 。
您的应用会验证 token ，并从其负载中获取用户名。
您的应用根据用户名联系数据库并获取用户信息。
您的应用会将用户带到其页面并提供存储在数据库中的信息。
编写工作流程将是:
您的应用通过 token 获取用户的写入请求。
验证 token 。
根据唯一的用户名写入数据库。
关于mysql - AWS Cognito Identity ID 对 SQL 主键的适用性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49715894/