我正在开发一个平台，其中唯一的用户ID是来自Amazon Cognito身份池的身份ID。看起来像这样：“us-east-1：128d0a74-c82f-4553-916d-90053e4a8b0f”
该平台有一个MySQL数据库，其中包含用户可以查看的项目表。我需要添加一个收藏夹表，其中包含每个用户的每个收藏项。这个表可能会增长到数百万行。
'favorites'表格的布局如下：
userID, itemID, dateAdded
其中userID和itemID一起是复合主键。
我的理解是这种类型的userID（实际上是一个扩展的UUID，需要存储为char或varchar），索引性能很差。因此不建议将它用作数百万行的键或索引。
我的问题是：我的理解是否正确，我是否应该担心以后因此问题导致的表现？我可以采取哪些缓解措施来降低性能风险？
我的整体数据库知识不是很好，所以如果这是一个大问题...将收藏的列表移动到NoSQL表（其中userID作为键将允许持续访问时间），并检索数组在SELECT ... WHERE IN查询中使用的被收藏项目ID是否可以接受？
非常感谢！
答案 0 :(得分：3)
好的，我想在这里说一下为什么这不好，替代方案和应用程序的读/写工作流程。
为什么不：这不是一个好的架构，因为如果您的Cognito用户池出现问题，您就无法为每个用户重新填充相同的ID。此外，Cognito现在在更多地区提供;与去年相比。让我们说你的用户＆＃39;基地在印度尼西亚，现在Cognito可在新加坡使用;您想将您的用户池从东京迁移到新加坡;因为延迟问题;不仅你有移动用户的问题;你有填充数据库的问题;因此，您的方法缺乏可扩展性，可维护性并打破单一责任原则（更新Cognito需要您更新数据库，反之亦然）。< / p>
替代解决方案：将db索引保留到db域;并使用用户名作为数据库与Cognito用户池之间的链接。所以：
阅读工作流程将是：
用户身份验证：用户验证并获取令牌。
您的应用验证令牌，并从其有效负载获取用户名。
您的应用会与数据库联系，并根据用户名获取用户的信息。
您的应用会将用户带到其页面并提供存储在数据库中的信息。
写工作流程将是：
您的应用获取带有令牌的用户的写请求。
验证令牌。
根据唯一的用户名写入数据库。
答案 1 :(得分：2)
关于MySQL，如果您对主键使用UserID和CognitoID组合，则会对查询性能产生负面影响，因此不建议用于大型数据集。
然而，除非您有复杂的查询，否则使用NoSQL DynamoDB的甚至UserID更合适。您还可以使用AWS DynamoDB fine-grained access control连接Cognito Identity Pool来强制实施安全性。