数据库表单记录太大时(垂直分区+水平分区)

1. 限制数据范围: 比如当用户查询订单历史时,我们控制在一个月的范围内
2. 读写分离:主库负责写,从库负责读(分为一个主库:用于写数据,多个从数据库:用于读数据), 主从库之间通过某种机制进行数据的同步,是一种常见的数据库架构.
   使用场景:读的多写的少…问题:主从数据一致性问题,
3. 垂直分区: 用数据库表拆成连个独立的表,根据数据表列拆分.当写入操作一旦增加的时候，那么主从数据库将花更多的时间的放在数据同步上，这个时候服务器也是不堪重负的；那么就有了数据的垂直分区，数据的垂直分区思路是将写入操作比较频繁的数据表，把这个两个表分离出来，放在不同的服务器，如果这两个表和其他表存在联表查询，那么就只能把原来的sql语句给拆分了，先查询一个表，在查询另一个，虽然说这个会消耗更过性能，但比起那种大量数据同步，负担还是减轻了不少.缺点:主键产生冗余, 引起join操作,让事务更复杂.
   
4. 水平分区: 当单表，数据量只增不减，历史数据又必须要留存，非常容易成为性能的瓶颈，而要解决这样的数据库瓶颈问题，就需要水平分区.将数据库表分片,每一个分片中的数据没有重合，所有分片中的数据并集组成全部数据
   水平分区后,数据表还都在一台机器上,对提升MySQL 并发性能没有意义,所以水平拆分最好分库.
   数据库分片的两种常见方案：
   客户端代理： 分片逻辑在应用端，封装在jar包中，通过修改或者封装JDBC层来实现。 当当网的 ShardingJDBC 、阿里的TDDL是两种比较常用的实现。
   中间件代理： 在应用和数据中间加了一个代理层。分片逻辑统一维护在中间件服务中。 我们现在谈的 Mycat、360的Atlas、网易的DDB等等都是这种架构的实现。