亿级用户大表如何作水平拆分？

　　一般面对几千万级的数据，刚开始可能都是把数据放在MySQL的一个单库单表里，但往往这么大量级的数据到后期，数据库查询速度就很慢，因为数据量级太大，导致表的索引很大，树的层级很高，进而导致搜索性能下降，而且能放内存缓存的数据页是比较少。
　　所以推荐MySQL单表数据量不超过1000w，最好是在500w内，若能控制在100万以内，那是最佳选择，基本单表100万以内的数据，性能上不会有太大的问题，前提是，只要你建好索引就行，其实保证MySQL高性能通常没什么特别高深的技巧，就是控制数据量不要太大，另外就是保证你的查询用上了索引就行。
　　针对该问题，就能分库分表，可选择将该用户大表拆分为比如100张表，那么此时几千万数据瞬间分散到100个表里去，类似user001user002user100
　　这样的100个表，每个表也就几十万数据而已。
　　其次，可将这100个表分散到多台数据库服务器上去，此时要分散到几台服务器呢？你要考虑两个点，一个是数据量有多少个GBTB，一个是针对用户中心的并发压力有多高。
　　互联网公司对用户中心的压力不会高到离谱，因为一般不会有很多人同时注册登录或同时修改自己的个人信息，所以并发不是大问题。
　　数据量层面，一般1亿行数据，大致在1几GB之间的范围，和具体你一行数据有多少个字段也有关，所以说你几千万的用户数据，往多了说也就几个GB。这点数据量，对服务器存储空间没压力。
　　综上，此时你完全能给他分配两台数据库服务器，放两个库，然后100张表均匀分散在2台服务器。分的时候，注意指定一个字段来分，一般就指定userid，根据用户id进行hash后，对表进行取模，路由到一个表里去，这就能让数据均匀分散。
　　至此搞定用户表的分库分表，只要给系统加上数据库中间件技术，设置好路由规则，即可轻松对2个分库上的100张表crud。平时针对某个用户增删改查，直接对他的userid进行hash，然后对表取模，做个路由，就知道到哪个表里去找这个用户的数据了。
　　但是这里可能会出现一些问题：用户在登录时，可能不是根据userid登录，而是根据username、手机号，此时你就没有userid了，怎么知道去哪个表里找这个用户的数据判断是否能登录？对此。常规方案是建立一个索引映射表，搞个表结构为（username，userid）的索引映射表，把username和userid一一映射，然后针对username再做一次分库分表，把这个索引映射表可拆分为比如100个表分散在两台服务器。然后用户登录时，就能根据username先去索引映射表里查找对应userid，比如对username进行hash，然后取模路由到一个表里去，找到username对应的userid，接着根据userid进行hash再取模，路由到按照userid分库分表的一个表里，找到用户的完整数据。但这种方式会把一次查询转化为两个表的两次查询，先查索引映射表，再根据userid去查具体的数据，性能有损耗，不过有时为解决分库分表问题，也只能用这种方案。
　　另外就是若公司运营团队里，有用户管理模块，需要对公司的用户按照手机号、住址、年龄、性别、职业等各种条件搜索，这咋办？
　　没啥好办法，基本上就是要对你的用户数据表进行binlog监听，把你要搜索的所有字段同步到ES，建立好搜索的索引。然后你的运营系统就可以通过ES进行复杂的多条件搜索，ES是适合干这个事儿的，然后定位到一批userid，通过userid回到分库分表环境里去找出具体的用户数据，在页面上展示出来即可。
　　这就是一套比较常规和完整的分库分表的方案。