MySQL水平垂直拆分分表分库分片分表，是业务逻辑上分的。如userid,name,addr一个表，为了防止表过大，分成2个表。t1:userid,nameT2:userid,addr分库，对业务透明，在物理实现上分成多个表，逻辑上还是一个表。按照时间分区，大部只查询最近的订单数据，那么大部分只访问一个分区，比整个表小多了，数据库可以更加好的缓存，性能也提高了。这个是以数据库分的，应用程序透明，无需修改。分片，业务透明，在物理实现上分成多个服务器，不同的分片在不同服务器上。分区可以把表分到不同的硬盘上，但不能分配到不同服务器上。一台机器的性能是有限制的，用分片可以解决单台服务器性能不够，或者成本过高问题。当分区之后，表还是很大，处理不过来，这时候可以用分片。orderid,userid,ordertime,.....userid%4=0，用分片1userid%4=1，用分片2userid%4=2,用分片3userid%4=3，用分片4上面就是一个简单的分片路由，根据userid选择分片，即不同的服务器。为什么要分片一个生产系统刚开始业务量较少，一个应用一个数据库足以应付。随着用户量增大，访问量增大，数据量增大，单库已经力不从心。互联网应用架构需要具备高可用高并发可弹性扩容的能力，所以当数据库压力与日俱增，需要妥善的扩容机制。分片实现数据层中间件TDDL淘宝Cobar阿里B2BMycat（前身是Cobar）Sharding-jdbc当当网Mysql-proxy官方,负载平衡,读写分离,failoverHibernateShard多数据库水平分区解决方案垂直拆分垂直拆分是指，将一个属性较多，一行数据较大的表，将不同的属性拆分到不同的表中，以降低单库（表）大小，达到提升性能的目的的方法，垂直切分后，特点：（1）每个库（表）的结构都不一样（2）一般来说，每个库（表）的属性至少有一列交集，一般是主键（3）所有库（表）的并集是全量数据用户表：user_base(uidbigint,namevarchar(16),passvarchar(16),ageint,sextinyint,…);user_ext(uidbigint,signvarchar(64),introvarchar(256)…);垂直拆分依据当一个表属性很多时，垂直拆分依据主要有几点：（1）将长度较短，访问频率较高的属性尽量放在一个表里(?)，这个表暂且称为主表（2）将字段较长，访问频率较低的属性尽量放在一个表里，这个表暂且称为扩展表如果1和2都满足，还可以考虑第三点：（3）经常一起访问的属性，也可以放在一个表里优先考虑1和2，第3点不是必须水平拆分水平切分是指，以某个字段为依据（例如userId），按照一定规则（例如取模），将一个库（表）上的数据拆分到多个库（表）上，以降低单库（表）大小，达到提升性能的目的的方法，水平切分后，各个库（表）的特点是：（1）每个库（表）的结构都一样（2）每个库（表）的数据都不一样，没有交集（3）所有库（表）的并集是全量数据水平拆分(单key)范围法，以用户中心的业务主键userId为划分依据，将数据水平切分到两个数据库实例上去：user-db1：存储0到1千万的userId数据user-db2：存储1到2千万的userId数据范围法的优点是：切分策略简单，根据userId，范围，能快速定位到数据在哪个库上，扩容简单，如果容量不够，只需要增加数据库实例范围法的不足是：userId必须要满足递增的特性数据量不均，新增的user-db3，在初期的数据会比较少请求量不均，一般来说，新注册的用户活跃度会比较高，故user-db2往往会比user-db1负载要高，导致服务器利用率不平衡水平拆分(单key)哈希法，也是以用户中心的业务主键userId为划分依据，将数据水平切分到两个数据库实例上去：user-db1：存储userId取模得1的uid数据user-db2：存储userId取模得0的uid数据哈希法的优点是：切分策略简单，根据userId，按照hash很快能够定位到数据在哪个库上数据量均衡，只要userId是均匀的，数据在各个库上的分布一定是均衡的请求量均衡，只要userId是均匀的，负载在各个库上的分布一定是均衡的哈希法的不足是：扩容麻烦，如果容量不够，要增加一个库，重新hash可能会导致数据迁移，如何平滑的进行数据迁移，是一个需要解决的问题水平拆分带来的问题如果查询条件是用户id，根据用户id可以按照范围、哈希取模来定位数据落点，查询数据。如果查询条件不是用户id呢？分析用户，前台访问...
