在实际的互联网项目中，往往数据量到了一定的量级，就必须进行分库分表。那么究竟如何分库分表才是合理的。本文将结合实际的应用场景进行分析。

应用场景：用户中心数据库切分架构实践

用户中心是作为一个常见的业务系统，包含注册、登录、用户信息查询基础服务。

用户的核心元数据为：

User(uid,mobile,nickname,password)

在业务初期，往往单库就能满足需求：

当数据量越来越大时，需要对数据库进行水平切分。

切分的方式通常有两种：range和hash。

我们通常采取哈希取模的方式进行切分，以用户中心的业务uid为划分依据，将数据水平切分到n个数据库实例上去：

哈希取模的优点：

1. 切分方式简单，能够快速定位到数据存放在拿个数据库中；

2. 数据量均衡：数据在各个库上的均衡分布，能极大提升整体查询效率

哈希取模的不足：

扩容时需要进行部分数据迁移，所以最好一开始就预估好数据量。

问题一：如何hash能最大程度减少扩容时需要迁移的数据库数量？

这个问题比较简单，留给读者思考。

针对这个问题，较为常见的有两种解决方案。

方案一：建立nickname至uid反向索引表

不足之处：增加存储空间，同时需要多出一次查询。

方案二：将nickname作为因子融入uid中。

具体做法：

1. 在用户注册时，设计函数gene=f(nickname)

2. 生成60位的全局唯一id，作为用户的标识

3. 把4位的gene也作为uid的一部分

4. 生成64位的uid，由id和gene拼装而成，利用gene分库插入数据

5. 用nickname来访问时，先通过f(nickname)再次复原gene

通常我们的做法是写入数据时同步一份数据供运营后台单独使用，独立部署MySQL实例，尽量不进行分库分表，以满足复杂的数据查询需求。