数据库水平分区，相对垂直分区，需要做的工作和事情要多一些，但是对一些行数据特别多的表，非常有必要。

    在我在BDC项目中的不断优化中，总结了下面几种常用的数据库水平切分方法：

1.  表分区；

2.  表拆分；

3.  表分库；

表分区

表分区是ORACLE和新版本的MYSQL数据库中，一个非常强大的功能。非常值得学习。

但是表分区如果用不好，性能反倒会下降。我记得我们的另外一个项目组，他们就尝试使用表分区，于是安排了一个没有相关经验的开发人员去研究，研究了几天，然后发现速度更加慢了，于是，表分区的计划就此终止。这是题外话。

    在选定表分区这个方案之后，首先要做的第一件事情，那就是要树立信心，表分区在处理大表数据的情况下，是一定有效果的，如果效果不明显或者没效果甚至效果变差了，那么首先要考虑是不是用的地方不太对。

    先说我们项目的实际情况，核心电话表当初的大小是1.2亿，我们选择的方案是表分区，那么接下来就是要根据数据情况，对这些数据进行不同维度的区分，让它更好的为业务服务。

我们的表中有一个很关键的内容，那就是地区；每一个电话信息，对应一个地区，这个是我们全国性电信数据的一个基本特征。

    那么是区分到省一级呢，还是到地市一级呢？我们有数据的省级行政区是32个，地市是300多个。分区不能太零碎，除非有确切的需要，否则以后运维是一个非常头疼的事情。那么我们在省一级区划上作为分区的条件。

    分区设计了，如果在SQL中就要体现出来，如果不体现分区，有可能会让效率降低。

    使用分区比较简单，一种是直接明确分区，比如

select * from tel PARTITION (310000) ；其中PARTITION (310000)是指上海的数据分区，其中310000是上海市对应的国家标准编码；

这是一种写法，我个人更加倾向于另外一种写法：

Select* from tel t where t.prov_code = 310000

其中，分区的标注就是创建在prov_code 这个字段上，ORACLE会自动调用分区的特性。

    就结果而言，通过类似的分区改造之后，峰值吞吐量从以前一天400万数据，数据库就要挂掉，最高达到了一天处理1200万数据，数据库貌似还有余力，效果还是不错的。

    表分区涉及的概念和功能蛮多的，有空整理下这方面的内容。

表拆分

    表拆分是一门古老的技术，也很实用。我们很久以前做电信黄页，那个时候表分区还没有成熟，我们处理大表最常用的技术就是表拆分了。

    表拆分从逻辑上非常简单，我们有一张9000万数据的号簿表，包含了31个省公司的号簿数据，这些数据同时由31个省公司进行维护。

    9000万的数据，无论是检索，修改，删除，对性能的影响都是很高。那就按照省份直接进行拆分吧。创建出31张表替代这一张，然后创建一个全国性视图，供集团使用。

表分库

    我们在表分区里提到了隔壁一个项目组，尝试使用表分区没有成功，但是活人不能被尿憋死，他们也找到了他们适合的方法，这个办法就是表分库。

    表分库是什么呢？其实我们的数据库主备机制，就是一个表分库的雏形。他们是怎么做的呢，首先准备硬件，购买了一组数据库硬件；然后把现有的数据库复制一份到新硬件上去，把业务数据清理干净，把常量数据保留；然后对系统做简单的调整，长江南边的进入老系统，访问老数据库；长江北面的进入新系统，访问新数据库。

    除了花钱有一点之外，改造风险确实蛮小的。当然，不是所有的系统都能这样分库。

    综上所述，当数据库到达一定规模，垂直切分和水平切分都是项目负责人必须要考虑的问题，无论使用哪种方式，都需要在了解业务的基础上，根据本系统的实际情况，选择一个最合适的方法。

数据库优化-水平切分-以及在实际项目中的应用