背景-我目前的理解-由于所有的成员数据都在同一个分区中，当用户基数增加到数百万时，可能会导致长表扫描。
目前，我仅根据电子邮件和密码向系统注册用户。我还有一个User表，它驻留在Azure SQL上，我在应用程序级别保留了两者之间的约束。"外键"是电子邮件地址。
使用会员资格提供程序搜索用户是通过电子邮件而不是UserId/key完成的。
除了主页之外，网站的其余部分需要进行身份验证，因此我预计会员资格的使用将很重要，但不是很大，因为经过身份验证后，用户将被缓存几分钟。
您认为使用基于成员关系的表存储对于数百万用户来说通常是一个很好的实践吗?
对于我的具体情况，你有什么建议吗?
成员提供程序是2005 . net 2遗留下来的，应该摆脱它的痛苦。它在现代网络架构中没有立足之地。应用程序应该使用基于声明的授权，并将身份转移给功能更强大的服务。看看Azure ACS, Azure Active Directory, Thinktecture Identity Server，它们的组合，或者其他令牌服务。
如果你认真考虑能够扩展到数百万用户，那么你需要认真考虑关于身份——因为它很重要。使用会员资格提供程序将使您陷入与您的目标不一致的架构角落。
我记得，表成员关系提供程序没有得到官方支持，可能在一段时间内没有更新。因此，除了最基本的演示目的外，我对使用它犹豫不决。我建议使用Windows Azure Active Directory。该服务对基本身份管理是免费的，并且可以很容易地集成到应用程序中。Windows Azure活动目录也是Office 365使用的相同解决方案，因此它应该非常方便地满足您的需求。