怎么处理上亿级别的用户列表数据？

我们假设一般项目的用户有哪些基础应用功能呢？一般至少应该有“注册/登录” 和 “填写/修改用户资料”两个基本基本功能是吧？那么我们就根据这两个基本的功能来设计表，如果有其他扩展功能，可以增加其他扩展表方式，本章不讨论其他扩展表的设计。

针对注册/登录功能，我们采用hash散列设计 user_register 表，表只有三列，分别为user_id，user_name，password，把user_name做为hask_key进行hash散列，方式：把user_name进行md5加密变成16进制的数字，然后转化成10进制数字，采用hash散列算法，就可以判断是存储到哪个库的哪个表。可以设计10个库，每个库100个表，表里面的user_name存储的是原始的user_name值，hash散列算法只是实现判断具体存储在哪个库的哪个表而已，这样用户在注册或者登录时，就可以引导用户连接到具体的分表去操作。

针对“填写/修改用户资料”，我们根据 user_id 进行hash散列，因为user_id本身已经是数字，所以直接计算就可以了，比较简单。
————————————————
版权声明：本文为CSDN博主「xpb1980」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/xpb1980/article/details/31032369

 

疑问：1.哈希算法能一次就确定A用户名的所在库+所在表吗？还是要多次哈希

2.看起来，哈希方法只是处理了把用户名改成了数字，然后匹配一下而已。为什么不直接使用用户id这个唯一标记直接查找？01001xxxxxx就代表01库001表某某某，不是更方便吗。

3.使用哈希方法的话，如果用户后面发生了修改用户名的操作，是不是要进行数据迁移？

4.10个库每个库100张表，一共1000张表。以mysql为例，每张表平均需要存10w条。加上哈希可能不均匀，峰值可能突破20w条，会不会突破单张表的存储上限？