背景 - 我目前的理解 - 由于所有成员数据都将在同一个分区中，因此在用户群增长到数百万后可能会导致长时间的表扫描。
目前，我仅根据电子邮件和密码将用户注册到我的系统。我还有一个驻留在 Azure SQL 上的用户表，并且我在应用程序级别保留了两者之间的约束。“外键”是电子邮件地址。
使用会员提供者搜索用户是通过电子邮件而不是通过 UserId/key 完成的。
除了主页之外，站点的其余部分都需要进行身份验证，因此我预计 Membership 的使用会很重要，但不会很大，因为在身份验证后，用户会被缓存几分钟。
您认为对于数百万用户来说，使用基于成员资格的表存储通常是一种好习惯吗？
你会为我的具体情况推荐什么？
我记得，表成员资格提供程序不受官方支持，并且可能在一段时间内没有更新。因此，除了最基本的演示目的之外，我会犹豫将其用于任何用途。我是否可以建议考虑使用 Windows Azure Active Directory。该服务对基本身份管理是免费的，并且可以很容易地集成到应用程序中。Windows Azure Active Directory 也是 Office 365 使用的相同解决方案，因此它应该可以轻松满足您的需求。
成员资格提供程序是 2005 .NET 2 的遗物，应该摆脱它的痛苦。它在现代 Web 架构中没有位置。应用程序应该使用基于声明的授权并将身份卸载到功能更强大的服务。查看Azure ACS、Azure Active Directory、Thinktecture Identity Server、它们的组合或其他令牌服务。
如果您认真考虑能够扩展到数百万用户，那么您需要认真考虑身份 - 因为它很重要。使用会员服务提供商会将您描绘成一个与您的抱负不符的建筑角落。