我正在开发一个平台，其中唯一用户 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 是可接受的替代方案吗？
非常感谢！