账号表 超kw条 用mysql 怎么快速存储快速查询

Question

账号表 超kw条 用mysql 怎么快速存储快速查询 而且上限多少个未知比如 类似淘宝 或者 网易的账号。

Answer 1

正好做过两个千万级的账号系统，简单说一下。
首先其实千万真的不算大，而且账号系统这种查询相对简单，无非有几种查询，按userid，按email，按phonenumber等等。如果你要在这张表上再做什么地区、年龄的条件查询，那当然是不太靠谱，谁干谁悲剧。
既然都是主键查询，或者简单索引查询，那就算放一张表也不是无法承受的。顺便做个主从读写分离减压又备份。
如果，你的字段多到离谱那可以考虑一下纵向拆分，比如常用字段在一个表，非常用字段一个表。
当然，数据再多你可以考虑直接按主键做横向分库分表，最简单方便的就是userid取模了。只是在做批量userid查询多个用户信息的时候可能要费事点，当然，我相信你肯定会做一个userid对应用户信息的缓存了吧。一级或者两级缓存，保证活跃的用户信息都能在里面，基本也够了。
上面是针对你只有一个用户表的情况，实际上，一般的用户表可能有两个功用：一是用户登陆注册，二是用户信息查询管理。
这两个功能其实可以分开来做，登陆注册相关操作在一套表，用户信息管理在另一套表，这里面可能要做一些数据冗余。比如你的邮箱字段可能在两个表里都有，更新记得要同步。

Answer 2

百度了一下，http://www.cnblogs.com/luxf/archive/2012/02/08/2343345.html

Answer 3

千万条必须分表分库，甚至要动用集群运算。

分库的最大麻烦在于方法选不好容易不均衡。以英文为例，如果简单的按首字母分配，那么Q、X、Z等就会异常的少，E、I等就会特别的多。你需要一个均衡的分配方法。做HASH取首个16进制数是个不错的主意。

更多的细节，都需要看你的具体需求而定，只言片语的问题是无法回答的。

Answer 4

建索引效果还是非常明显的

一提到千万数据，我就想到前不久网上那两千万酒店记录

Answer 5

kw级别，其实不需要分表分库，但是，鉴于你需要多个字段查询，如果索引建的太多，维护索引的成本就会过高。
但是，因为你要用多个字段作为查询条件，那么也不方便使用分表分库的方法。假如你使用userid根据一定规则分表的话，那么，用userid查询的时候，你可以找到要从哪个表里面查询，但是，用其他字段查询的时候怎么办？总不能每个表都查一遍吧。
所以最好的方法还是减少查询条件，控制在4，5个之内，这样维护索引的成本应该也还好，特别是数据不需要频繁更新的时候。