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