压力型后台

读写分离-分离读操作和写操作，避免相互影响
水平拆分，因为单表太大查询性能太差，减小查询氛围提高反应速度，按照业务维度拆分，比如交易数据最近一周的读写均衡，而一周以前的读远远大于写。此时需要两张表进行数据的转移[先备份]。然后就是少数商户会进行大多数交易，于是自然将频繁交易商户单独拆开，低频商户的实时查询的范围自然更小，不会受到前者影响。

- 首先读写分离，基本操作，分离读写

- 然后做垂直拆分，狭义的技术角度的水平拆分

- 广义的业务角度上的水平拆分—>水平拆分会导致排序问题，局部排序不等于全局排序

水平拆分导致的分页及排序问题：水平拆分后，想要分页检索的话，传统思维select count(id) from table,这个数量查询都是比较耗时的，不过我们不一定需要完整地显示页数，比如TB上我们可以直接显示前2000条数据，100页，20条/页。对于商家，如果需要检索交易数据，一般而言查看前10页是比较频繁的，同时如果真的需要查看全部数据，获得某个时间段的交易数据，我们后台单独开线程提供下载，对于此种完整查询是需要耗时的，所以通过网页展示并不是理想方案。
排序问题，可以依靠一些策略从多个库表中检索出数据在服务层归并进行排序
水平拆分的表设计问题：

- 主键自增，为了控制数据分布均衡，对于自增类型，可以使用1、3、5、7、9另外一张表适用2、4、6、8、10类似的自增序列，或者机器A承担1E条数据是较好的上限，那么机器B就从1E+1开始取ID。前者无法解决将来的上限问题，后者无法解决数据分布不均问题。

- 整数哈希取余，如果主键是业务唯一字段，可以通过该方式决定该条数据的存取位置。

- 一致性哈希，解决拓展及单台服务器故障问题[Memcached集群也会用到该方案]

垂直拆分：比如某些数据不大但是读写连接数多。
拆分会带来很多问题，比如join查询失效，拆分就是为了减轻数据库压力，so让DB安心读写，计算交给服务层。同时拆分引起数据结构和分布变化，如果不希望将来拆分引起业务代码大改动，就需要定义好数据服务接口，减少后期变动。
缓存技术：使用Memcached Redis  每一时间段写入到持久层
检索的要点在于范围，搜索范围越小，速度就越快，所以对表进行水平拆分，拆分就会带来查询问题，我们需要对多表查询结果就行归并、排序。拆表分表让数据库结构发生变化，这段时间的监控要求提高，需要有备份替代方案在手，于是有人自然想另起炉灶。
单库数据库-->数据库读写分离-->缓存技术[剥离价值不高数据实时性不高数据]-->搜索技术-->数据的垂直拆分-->数据的水平拆分

数据库的读写性能一般是一个系统的平静所在，如果通过一般成本下的分库分表都无法解决性能问题，就需要使用NoSQL了。