#数据库水平拆分策略
当业务达到一定的规模，那么就需要对业务所使用数据库进行水平切分，用于减少单台数据库的压力。常用的切分策略有这么几种:
- 化区域拆分 例如：0~100000在DB1 200000~3000000 在DB2 等等 优点:拆分简单 缺点：数据分布不均匀
- hash取模 例如: userid.hashcode() % table_count，table_count最好是2的倍数，方便数据库扩展 优点：数据分布均匀 缺点：不好扩展
##场景一：用户表
t_user(uid, name, pqssword)
使用场景:
- where name=xxx and possword=xxx 登录的sql，只有在登录的时候使用到，使用频率在1%左右
- where uid=XXX； 登录后的各种操作都需要，使用频率97%+ 最主要的就这两种使用场景。按照使用频率来看，只要用uid字段来进行数据库的切分就可以了。当sql语句没有uid字段时操作所有表即可。
##场景二：帖子表
t_info(infoid, uid, subject, context)
使用场景:
- where infoid=xxx 根据帖子ID查找帖子信息,使用频率在50%
- where uid=xxx 根据用户ID查找帖子信息，使用频率50% 从uid中取出固定的一部分，用于生成帖子ID。 uid取出的那一部分，用于分库分表。这样两个字段都可以用于分库分表。
##场景三：好友表
t_friend(uid, friend_id, creattime, xxx)
使用场景:
- where uid=xxx 根据uid查找好友信息。使用频率60%
- where friend_id=xxx 根据friend_id 查找用户信息，使用频率40% 因为这两个id不能像帖子表中的id那样关联，因此不能使用场景二。因此可创建反向好友表，此表中只存两个字段（friend_id, uid) 在好友表中，使用uid分库分表。反向好友表中使用friend_id查找。
##场景四：订单表
t_order(order_id, buyer_id, seller_id, addr, phone...)
使用场景:
- where order_id=xxx
- where buyer_id=xxx
- where seller_id=xxx 可结合场景二，解决order_id的生成，结合场景三，创建卖家买家反向表。