为何需要分库分表
根据阿里云上的测试，8/32 支持 1300事务数 25000并发请求数；16/64 2000事务数，40000并发请求数，mysql并发请求数不高。
方案1：数据量不大，读压力大，写压力不大的情况下加缓存。或者读写分离。
方案2：数据量大，并发读写操作超过了单数据处理能力。这个时候需要分库分表了。
垂直切分
将表按照功能模块、关系密切程度划分出来，部署到不同的库上。也就是分库。适用于表多的情况。
水平切分
当一个表中的数据量过大时，我们可以把该表的数据按照某种规则，例如userID散列，进行划分，然后存储到多个结构相同的表，这就是分表。
切分的选择
应该使用哪一种方式来实施数据库分库分表，这要看数据库中数据量的瓶颈所在，并综合项目的业务类型进行考虑。
如果数据库是因为表太多而造成海量数据，并且项目的各项业务逻辑划分清晰、低耦合，那么规则简单明了、容易实施的垂直切分必是首选。而如果数据库中的表并不多，但单表的数据量很大、或数据热度很高，这种情况之下就应该选择水平切分，水平切分比垂直切分要复杂一些，它将原本逻辑上属于一体的数据进行了物理分割，除了在分割时要对分割的粒度做好评估，考虑数据平均和负载平均，后期也将对项目人员及应用程序产生额外的数据管理负担。
在现实项目中，往往是这两种情况兼而有之，这就需要做出权衡，甚至既需要垂直切分，又需要水平切分。我们的游戏项目便综合使用了垂直与水平切分，我们首先对数据库进行垂直切分，然后，再针对一部分表，通常是用户数据表，进行水平切分。
问题挑战
在分片之后的数据库中并不一定能够正确运行。
跨库事务也是分布式的数据库集群要面对的棘手事情。 合理采用分表，可以在降低单表数据量的情况下，尽量使用本地事务，善于使用同库不同表可有效避免分布式事务带来的麻烦。 在不能避免跨库事务的场景，有些业务仍然需要保持事务的一致性。 而基于XA的分布式事务由于在并发度高的场景中性能无法满足需要，并未被互联网巨头大规模使用，他们大多采用最终一致性的柔性事务代替强一致事务。
分表的2个方式
１．事先预估好了，直接根据一定规则把表划分为多个。比如用户表。事先建ｎ个这样的表，user1,user2,user3。然后根据用户的ID来判断这个用户的聊天信息放到哪张表里面，你可以用hash的方式来获得，可以用求余的方式来获得，方法很多。
２.使用merge的方式建立映射。但是要求很多不能是innodb存储引擎。一般不使用。