大字段垂直拆分策略相对于适度冗余策略在做法上可以说是完全相反的。适度冗余策略是将别的表中的字段拿过来在自己身上也存一份，而大字段垂直拆分简单来说就是将自己身上的字段拆分出去放在另外的表里。什么样的字段适合从表中拆分出去呢？

    首先，肯定得是大字段。为什么？原因很简单，就是因为它大。大字段一般都是存放着一些较长的detail信息，如文章的内容、帖子的内容、产品的介绍等。

    其次是和表中其他字段相比访问频率明显要少很多的。由于大字段存放的内容较多，大部分情况都占整条记录的80%以上，而数据库中数据在数据文件中的格式一般都是以单条记录为单位来存放的。也就是说，如果要查询某些记录的某几个字段，数据库并不是只需访问要查询的那几个字段，而是需要读取其他所有字段（可以在索引中完成整个查询的情况除外）。这样，就不得不读取包括大字段在内的很多并不相干的数据。而由于大字段所占的空间比例非常大，自然所浪费的IO资源也就相当大了。

MySQL可扩展设计需要遵循高可用及数据安全原则，经过scale out设计之后，刺痛整体性可扩展性确实会得到很大的提高，整体性能也很容易得到较大的改善。但是，系统整体的可用性和维护方面却变得比以前更加困难。因为系统整体架构复杂了，不论是应用程序还是数据库环境方面都会比原来更为庞大，更为复杂。这样，最直接的影响就是维护难度更大，系统监控更难。

    如果这样的设计改造所带来的后果是系统经常性地crash，经常性地出现down机事故，大家肯定是无法接受的。因此，必须通过各种技术手段来保证系统的可用性不会降低，甚至在整体上有所提高。
这就引出了scale out设计过程中的另一个原则，也就是高可用性的原则。不论如何调整设计系统的架构，系统的整体可用性不能降低。

搭建分布式数据库集群的时候，很多人都比较关心事务的问题。因为事务是数据库中非常核心的功能。

    在传统的集中式数据库架构中，事务的问题非常好解决，可以完全依赖数据库本身非常成熟的事务机制来保证。但是数据库作为分布式的架构之后，很多原来在单一数据库中所完成的事务现在需要跨多个数据库主机，这样原来的单机事务就需要引入分布式事务的概念。

    分布式事务本身是一个非常复杂的机制，不管是商业的大型数据库系统，还是各开源数据库系统。虽然大多数数据库厂家基本上都实现了这个功能，但或多或少地存在限制，而且存在一些Bug，可能造成某些事务不能很好的保证，或者是不能顺利地完成。

 MySQL的复制可以是基于一条语句或一条记录的，你可以在MySQL的配置参数中设定复制级别，不同复制级别的设置会影响到Master端的Binary Log记录成不同的形式。

    1、Row Level

    Binary Log会记录成每一行数据被修改的形式，然后在Slave端再对相同的数据进行修改。

    优点：在Row Level模式下，Binary Log可以不记录执行的Query语句的上下文相关信息，只需要记录哪一条记录被修改了，修改成什么样了。所以Row Level的日志内容会非常清楚地记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题。

NDB存储引擎也叫NDB Clister 存储引擎，主要用于MySQL Cluster分布式集群环境，Cluster是MySQL从5.0版本才开始提供的新功能，本文并不只是介绍NDB存储引擎，因为离开了MySQL Cluster整个环境，NDB存储引擎也将失去太多意义。

    简单地说，MySQL Cluster就是在无共享存储设备的情况下实现的一种内存数据库Cluster环境，主要是通过NDB Clister 存储引擎来实现的。

    一般来说，一个MySQL Cluster的环境主要由以下三部分组成。

MySQL物理备份所需文件主要包括以下三个方面：MyISAM存储引擎、InnoDB存储引擎、NDB Cluster存储引擎。

    1、MyISAM存储引擎

    MyISAM存储引擎的所有数据都存放在MySQL配置设定的“datadir”目录下。实际上不管使用的是MyISAM存储引擎还是其他任何存储引擎，每一个数据库都会“datadir”目录下有一个文件夹。在各个数据库中每一个MyISAM存储引擎表都会有三个文件存在，分别为记录表结构元数据的“.frm”文件、存储表数据的“.MYD”文件，以及存储索引数据的“.MYI”文件。由于MyISAM属于非事务性存储引擎，所以它没有自己的日志文件。所以MyISAM存储引擎在做物理备份时，除了备份MySQL系统共有的物理文件之外，就只需要备份上面的三种文件。

任何一个系统的硬件环境都会对性能起到非常关键的作用，这一点我想每一位朋友都是非常清楚的。而在数据库应用系统环境中，数据库自身的特点和在系统中的角色决定了它是整个系统中最难以扩展的部分。所以在大多数环境下，数据库服务器主机（或者主机集群）的性能在很大程度上决定了整个应用系统的性能。

    既然数据库主机资源如此重要，肯定很多朋友会希望知道，数据库服务器主机的各部分硬件到底谁最重要，它们对整体性能的影响各自占的比例是多少，以便能够根据这些比例选取合适的主机机型。但是我只能很遗憾的告诉大家，没有任何一个定律或法则可以很准确地给出这个答案。

数据的垂直切分，也可以称为纵向切分，将数据库想象成由很多个一大块一大块的“数据块”（表）组成，垂直地将这些“数据块”切分，然后把它们分散到多台数据库主机上面。这样的切分方法就是垂直（纵向）切分。

    一个架构设计较好的应用系统，其总体功能肯定是由很多个功能模块所组成的，而每一个功能模块所需要的数据对应到数据库中就是一个或多个表。而在架构设计中，各个功能模块相互之间的交互点越统一、越少，系统的耦合度就越低，系统各个模块的维护性及扩展性也就越好。这样的系统，实现数据的垂直切分也就越容易。

数据库主要是为应用程序提供数据存取相应的服务，提高数据库的扩展性，也是为了更好地提供数据存取服务能力，同时包括可靠性、高效性及易用性。所以，最根本的目的就是让数据层的存储服务能力得到更好的扩展性，让投入尽可能与产出成正比。

    我们都明白，数据本身肯定都需要有一个可以持久化地方，但是否有必要让所有冗余数据都进行持久化呢？我想大家肯定都会觉得没有这个必要，只要保证有至少两份冗余的数据进行持久化就足够了。而另外一些为了提高扩展性而产生的冗余数据，完全可以通过一些特别的技术来替代需要持久化的数据库，如内存Cache、Search，以及磁盘文件Cache和Search，等等。

实际上，除了使用比较熟悉的第三方关键的解决方案之外，如果有一定的技术实力，还可以通过自行实现的Cache软件来达到完全相同的效果。当然，也不要被上面所说的“技术实力”吓倒，其实并没有想象中的难。只要您不一开始就希望做出一个能够解决所有问题且包含其他第三方Cache软件的所有优点，还不能遗留任何缺点的软件。从小做起，从精做起，千万别希望一口气吃成一个胖子。自主研发实现Cache服务软件的前提是系统中存在比较特殊的应用场景，通过自主研发可以最大限度地实现个性化的需求。当然，也可以针对自己的应用场景进行特定的优