数据库优化顺序

  在数据库性能遇到瓶颈的时候，无非是会出现以下几种情况：无法获取连接，是因为在高并发的情况下数据库连接数不够；查询时间太久，是因为单表存储数据过多，数据库处理数据的效率降低；这些问题的出现我们首先应该想到的优化顺序应该是软件到硬件的优化。因为硬件的优化成本太高。

优化层面

sql与索引

  sql是存在于应用端的，这是我们首先要想着优化的点。sql的优化最终目的就是使用索引或者缩短执行时间。

表与存储引擎

  优化表结构，对表进行分区，对表结构进行拆分或者冗余处理，
或者对表结构比如字段的定义进行优化。使用性能高的存储引擎。

架构

  我们可以对数据库的架构进行优化，例如可以做数据库集群，读写分离。或者在数据库的上层做缓存减小数据库压力。

配置

  是数据库配置的优化，比如连接数，缓冲区大小等等，优化配置的目的都是为了更高效地利用硬件。

硬件

  升级硬件配置，例如使用高速固态硬盘和高性能cpu。

架构演进与分库分表

单一架构

  使用单一架构的时候，多个应用服务操作一个数据库实例，所有的表都存在一个数据库之中。这样在数据量上来的时候，势必会带来性能问题。这时，我们就需要考虑服务和数据库拆分。每个应用对应一个数据库。

多应用独立数据库

这个时候每个业务系统都有了自己的数据库，不同的业务系统就可以用不同的存储方案。

什么时候分表？

  当一个表的数据量过大，sql也进行了优化后，对该表的操作执行效率依然很低的时候，就需要考虑分表了。

垂直切分

垂直分表有两种，一种是单库的，一种是多库的。

单库

单库分表，比如：商户信息表，拆分成基本信息表，联系方式表，结算信息表，附
件表等等。

多库

  多库垂直分表就是把原来存储在一个库的不同的表，拆分到不同的数据库。
  比如：消费金融核心系统数据库，有很多客户相关的表，这些客户相关的表，全部单独存放到客户的数据库里面。合同，放款，风控相关的业务表也是一样的。
  当我们对原来的一张表做了分库的处理，如果某些业务系统的数据还是有一个非常快的增长速度，比如说还款数据库的还款历史表，数据量达到了几个亿，这个时候硬件限制导致的性能问题还是会出现，所以从这个角度来说垂直切分并没有从根本上解决单库单表数据量过大的问题。在这个时候，我们还需要对我们的数据做一个水平的切分。

水平切分

  当我们的客户表数量已经到达数千万甚至上亿的时候，单表的存储容量和查询效率都会出现问题，我们需要进一步对单张表的数据进行水平切分。水平切分的每个数据库的表结构都是一样的，只是存储的数据不一样，比如每个库存储 1000 万的数据。水平切分也可以分成两种，一种是单库的，一种是多库的。

单库

  银行的交易流水表，所有进出的交易都需要登记这张表，因为绝大部分时候客户都是查询当天的交易和一个月以内的交易数据，所以我们根据使用频率把这张表拆分成三张表：
  当天表：只存储当天的数据。
  当月表：在夜间运行一个定时任务，前一天的数据，全部迁移到当月表。用的是 insert into select，然后 delete。
  历史表：同样是通过定时任务，把登记时间超过 30 天的数据，迁移到 history
  历史表（历史表的数据非常大，我们按照月度，每个月建立分区）。

多库

  另一种是多库的水平分表。比如客户表，我们拆分到多个库存储，表结构是完全一样的。

后续更新