要分多少库，要预留一定bit的分库基因。
3.2、前台与后台分离
对于用户侧，主要需求是以单行查询为主，需要建立login_name/phone/email到uid的映射关系，可以解决这些字段的查询问题。
而对于运营侧，很多批量分页且条件多样的查询，这类查询计算量大，返回数据量大，对数据库的性能消耗较高。此时，如果和用户侧公用同一批服务或数据库，可能因为后台的少量请求，占用大量数据库资源，而导致用户侧访问性能降低或超时。
这类业务最好采用"前台与后台分离"的方案，运营侧后台业务抽取独立的service和db，解决和前台业务系统的耦合。由于运营侧对可用性、一致性的要求不高，可以不访问实时库，而是通过binlog异步同步数据到运营库进行访问。在数据量很大的情况下，还可以使用ES搜索引擎或Hive来满足后台复杂的查询方式。
五. 支持分库分表中间件
站在巨人的肩膀上能省力很多，目前分库分表已经有一些较为成熟的开源解决方案：
六. 参考
数据库分布式架构扫盲——分库分表（及银行核心系统适用性思考）
分库分表的思想
水平分库分表的关键步骤以及可能遇到的问题
从原则、方案、策略及难点阐述分库分表
Leaf——美团点评分布式ID生成系统
数据库水平切分架构实践-【架构师之路】公众号