当我们系统达到瓶颈时候，最影响系统性能的永远是最底层的。例如数据库，所以数据库优化相对重要，当数据库性能由于数据量过大导致达到瓶颈的时候，我们会选择对数据库拆分或者对表拆分，也就是分表分库。分表分库也分为2种拆分方式：水平拆分、垂直拆分
1.水平分表 就是把一个表拆分成多个字段相同的表，把数据分开保存到不同的表上。
例如一个user表有一亿用户，如果只用一张表储存查询的时候会很慢
但是如果分成10个表来储存这些用户，则每个表只需要保存1000W数据，这样效率就会大大提高
那如果分成10个表就需要制定相应的储存规则，例如通过 user 表的 userName字段进行hash取模来存放哪个表
2.垂直分表 如果一个表的字段过多及储存的空间较大则可以进行垂直拆分，就是把一个表的字段拆分开保存。
例如把user再拆分一个user_detail表，各个表保存不同的字段，然后使用ID关联，避免字段过多导致查询慢
3.水平分库 如果一个数据库实例承受不了目前的压力，则可以使用多个数据库实例，数据库直接存在相同的表。
因为数据库表都是相同的，与水平分表类似，通过规则把数据保存到不同的数据库
4.垂直分库 现在程序都是分布式或者模块化，一个服务器可能只负责某部分业务，数据库也可以使用类似的操作。
把不同业务的表分开储存到不同的数据库上
例如一个电商项目，把订单类的表与商品类的表分开到不同的数据库储存
分表分库之后带来的问题：
1.数据唯一性：即使同库分表或是分库分表都需要解决的一个问题就是ID唯一，保证多个表之间的数据ID是唯一的。
可以自定义主键生成器，主键生成规则最好符合数据库引擎的一些特性,比较可取的就是通过 时间+机器号+随机数，时间放到最前面是保证数值在递增
2.横向扩展：上面举例使用的是通过取模方式定位数据储存的库表，如果最开始取模是按10个表取，当我需要再加2个表则变成按12个表取模，这样新数据不会有问题，但是查询旧数据就存在问题。
当数据库需要进行拆分的时候，或多或少都需要对数据做一定迁移，把旧数据重新分配到不同表中
3.部分表无法通过join关联：例如把订单表与商品表拆开储存到不同的数据库，如果需要根据订单查询商品信息，则难以通过join关联查询。
如果可以冗余某些字段避免过多查询
可以使用FEDERATED引擎远程关联
4.数据库事务：还是使用订单表与商品表拆开储存到不同的数据库的例子，一个下单操作需要在订单类表添加订单信息，同时需要在商品类表扣除库存之类的，这之间的操作如何保证原子性。
可以使用某些分布式事务的中间件解决
5.维护成本更高：当单库单表变成多库多表，其中的关系更复杂，维护成本更高
分表分库的优点：
分表分库的目的永远只有一个： 因为数据库数据量过大导致效率低下，通过把数据拆分提高数据访问性能