数据库优化方案（百万级数据）

分表策略：

数据量剧增的时代，IO成本显得那么的高昂，使开发人员越来越多地关注数据库优化的技术，其中分表技术是最基本的一项方式

分表其实对于IO优化并不显得太有帮助，它更多的是给于数据库的减压（索引查找问题），它给于维护人员节省了很多工作

 

如：DBA想翻找2011年数据库里的数据（假设500GB）

     若不进行数据分表，2011~2012的数据全部都会挤在一张表内，当然，其实上面的是很夸张的数据量。

      2011~2012就会产生大概1500G的数据量，索引查找起来就要处理差不多500G的数据（当然，这只是乐观表现，如果索引多的话，那索引的数据量就远远不止這個量了）

 

接下来，如果他想备份某一部分的数据，或者把某部门数据锁死（只能读不能写），这样子的话就需要人工去抽取数据，然后做成数据表之后再进行备份，这样需要一定的数据量，处理起来也很繁琐，如果能让脚本完成类似工作是就好的。

分库策略：

分库策略主要面向的就是降低IO成本，尤其在SQL Server上表现的甚是明显，它存在文件组（指向多个文件，一般而言SQL Server上一个文件对应一个数据库。而文件组的概念，则是把多个数据文件合并成逻辑上的一个文件，但实际上操作的时候却是由文件组按负载分配写入数据，这样能减轻不同磁盘的读写压力，尤其是可以多个文件放在不同的磁盘上）可以直接对数据库实行分库策略。

 

读取数据库数据需要占用io资源这是必然的，我们可以通过磁盘阵列对磁盘读写压力进行缓解；但磁盘阵列的成本太高，我们有没有一种更加低廉的解决方案呢？分库策略正是为了解决这种情况，把可以把数据库的文件放在不同的磁盘上，在读取的时候，可以通过不同磁盘来进行读取。这样能大大减轻磁盘的读写压力。

分区表策略：

分区表，更多关注于的是数据在写入的过程，反而在读取的时候是比较繁琐的。因为它需要把多条数据放入不同的数据文件（或者是不同的库）中。5000条数据中20%存入一个读写速度较慢的数据库服务器当中，而80%的数据则存入到读写速度更快的数据库服务器。这样能更大效率上利用IO资源

主从表策略：

严格来说，它不算是完全数据库优化策略，它其实也算是一个安全策略（保存了多个数据备份）。但如果对于应用而言，一旦主数据库服务器宕机了，整个集群架构都会瓦解，根本不能继续工作。

 

既然如此，为什么还要用它呢？因为它是设置比较普遍，维护比较简单的一种缓解方案。一个主数据库服务器（master）写入操作，再同步到各个从数据库服务器（slaver）当中。而从数据库服务器则通过负载均衡软件给用户进行查询操作。（*注意，从数据库一般只进行读操作，写入操作只能通过主数据库服务器同步过来的数据库事务（有时候是单纯的日志）。）

 

这种方式会有一个挺大的弊端，如上而言，从数据库的数据是由主数据库通过日志或者事务进行同步的。所以从数据库的数据是有一定延时的，对于实时性较强的网站应用是不适用的。更多用于门户网站或者是数据采集网站，一种典型例子就是视频网站。