前言

资料库，简而言之，是放置统计数据的库房。它的存储容量非常大，能放置五百万、Monton、上万条统计数据。但资料库并并非随便地将统计数据展开放置，是有很大的准则的，不然查阅的组织工作效率会较低。当今是两个充满着统计数据的互

而他们常说的资料库事实上是指管理组织工作资料库的软件商品，即资料库信息系统（DBMS），而这也是他们常说的亲密关系型资料库。

资料库信息系统(Database Management System)是一类操纵者和管理组织工作资料库的软件商品，用作创建、采用和保护资料库，全称DBMS。它对资料库展开标准化的管理组织工作和掌控，以确保资料库的可靠性和准确性。采用者透过DBMS出访资料库中的统计数据，资料库管理组织工作员也透过dbms展开资料库的保护组织工作。它可使数个插件和用户用相同的方式在与此同时或相同关键时刻去创建，修正和查问资料库。绝大部分DBMS提供统计数据CYKDDL（Data Definition Language）和统计数据操作方式词汇DML（Data Manipulation Language），供采用者表述资料库的商业模式内部结构与职权束缚，与此同时实现对统计数据的新增、删掉等操作方式。

现阶段非主流的资料库信息系统有：Oracle、MySQL、SQL Server、MariaDB、PostgreSQL、DB2和Sybase等。

责任编辑主要就如是说MySQL。

MySQL如是说

MySQL是两个亲密关系型资料库信息系统，由瑞典MySQL AB 公司合作开发，现阶段归属于 Oracle 母公司商品。MySQL 是最盛行的亲密关系型资料库信息系统众所周知，在 WEB 应用领域各方面，MySQL是最合适的 RDBMS (Relational Database Management System，亲密关系资料库信息系统) 合作开发工具众所周知。

自甲骨文公司收购MySQL之后，MySQL在商业资料库与开源资料库领域的市场占有份额都跃居第一，这样的格局引起了部分业内人士的担忧，因为商业资料库的老大有可能将MySQL闭源，为了避免Oracle将MySQL闭源，而无开源的类MySQL资料库可用，MySQL社区采用了分支的方式——MariaDB资料库就这样诞生了，MariaDB是两个向后兼容的资料库商品，可能会在以后替代MySQL。

不过，这里还是建议大家选择更稳定且采用更广泛的MySQL资料库，能先测试MariaDB资料库，等采用的人员多一些，社区更活跃后再正式考虑采用也不迟。

MySQL的特性和优劣势

MySQL的特性

使⽤C和C++编写，并使⽤了多种编译器进⾏测试，确保源代码的可移植性

⽀持多种操作方式系统，如Linux、Windows、AIX、FreeBSD、HP-UXMacOS、NovellNetware、OpenBSD、OS/2 Wrap、Solaris等

为多种编程语⾔提供了API，如C、C++、Python、Java、Perl、PHP、Eiffel、Ruby等

⽀持多线程，充分利⽤CPU资源

优化的SQL查阅算法，有效地提⾼查阅速度

提供多语⾔⽀持，常⻅的编码如GB2312、BIG5、UTF8

提供TCP/IP、ODBC和JDBC等多种资料库连接途

提供⽤于管理组织工作、检查、优化资料库操作方式的管理组织工作⼯具

⼤型的资料库。能处理拥有上Monton记录的⼤型资料库

⽀持多种存储引擎

MySQL 软件采⽤了双授权政策，它分为社区版和商业版，由于其体积⼩、速度快、总体拥有成本低，尤其是开放源码这⼀特点，⼀般中⼩型⽹站的合作开发都选择MySQL作为⽹站资料库

MySQL使⽤标准的SQL统计数据语⾔形式

Mysql是能定制的，采⽤了GPL协议，你能修正源码来合作开发⾃⼰的Mysql系统

在线DDL更改功能

复制全局事务标识

复制⽆崩溃从机

复制多线程

还有最重要的一点是：开源免费不要钱使⽤范围⼴,跨平台⽀持性好,提供了多种语⾔的调⽤API

MySQL常用引擎及其优缺点：

MySQL的常用存储引擎有：MyISAM、InnoDB、MERGE、MEMORY(HEAP)、BDB(BerkeleyDB)等，最常用的是MyISAM与InnoDB两个引擎。

InnoDB 引擎(MySQL5.5以后默认采用)

灾难恢复性好支持事务采用行级锁支持外键关联支持热备份对于InnoDB引擎中的表，其统计数据的物理组织

MyISAM引擎

不支持事务采用表级锁，并发性差主机宕机后，MyISAM表易损坏，灾难恢复性不佳能配合锁，与此同时实现操作方式系统下的复制备份、迁移只缓存索引，统计数据的缓存是利用操作方式系统缓冲区来与此同时实现的。可能引发过多的系统调用且组织工作效率不佳统计数据紧凑存储，因此可获得更小的索引和更快的全表扫描性能

MEMORY 存储引擎

提供内存表，也不支持事务和外键。显著提高出访统计数据的速度，可用作缓存会频繁出访的、能重构的统计数据、计算结果、统计值、中间结果。采用表级锁，虽然内存出访快，但如果频繁的读写，表级锁会成为瓶颈只支持固定大小的行。Varchar类型的字段会存储为固定长度的Char类型，浪费空间不支持TEXT、BLOB字段。当有些查阅需要采用到临时表（采用的也是MEMORY存储引擎）时，如果表中有TEXT、BLOB字段，那么会转换为基于磁盘的MyISAM表，严重降低性能由于内存资源成本昂贵，一般不建议设置过大的内存表，如果内存表满了，可透过清除统计数据或调整内存表参数来避免报错服务器重启后统计数据会丢失，复制保护时需要小心

MySQL存储引擎MyISAM与InnoDB如何选择

1）InnoDB支持事务，MyISAM不支持，这一点是非常之重要。事务是一类高级的处理方式，如在一些列增删改中只要哪个出错还能回滚还原，而MyISAM就不能了。2）MyISAM适合查阅以及插入为主的应用领域，InnoDB适合频繁修正以及涉及到可靠性较高的应用领域3）InnoDB支持外键，MyISAM不支持4）从MySQL5.5.5以后，InnoDB是默认引擎5）InnoDB不支持FULLTEXT类型的索引6）InnoDB中不保存表的行数，如select count(*) from table时，InnoDB需要扫描一遍整个表来计算有多少行，但MyISAM只要简单的读出保存好的行数即可。注意的是，当count(*)语句包含where条件时MyISAM也需要扫描整个表。7）对于自增长的字段，InnoDB中必须包含只有该字段的索引，但在MyISAM表中能和其他字段一起创建联合索引。8）清空整个表时，InnoDB是一行一行的删掉，组织工作效率非常慢。MyISAM则会重建表。9）InnoDB支持行锁（某些情况下还是锁整表，如 update table set a=1 where user like %lee%

MySQL集群-高可用、负载均衡架构

MySQL是一款开源的亲密关系数据库商品，行业内大多对于MySQL的认知都是只能做小项目应用领域场景，适合中小企业。那么MySQL到底能否支持大型场景应用领域呢？

他们接下来如是说MySQL的大型场景应用领域，集群。

高可用架构对于互联网服务基本是标配，无论是应用领域服务还是资料库服务都需要做到高可用。对于两个系统而言，可能包含很多模块，比如前端应用领域，缓存，资料库，搜索，消息队列等，每个模块都需要做到高可用，才能确保整个系统的高可用。对于资料库服务而言，高可用可能更复杂，对采用者的服务可用，不仅仅是能出访，还需要有正确性确保，因此资料库的高可用方案是一直以来的讨论热点，今天就各种的高可用方案，谈一下个人的一些看法，如有错误，还请指正！！

在考虑MySQL资料库的高可用的架构时，主要就要考虑如下几各方面：

如果资料库发生了宕机或者意外中断等故障，能尽快恢复资料库的可用性，尽可能的减少停机时间，确保业务不会因为资料库的故障而中断。用作备份、只读副本等功能的非主节点的统计数据应该和主节点的统计数据实时或者最终保持一致。当业务发生资料库切换时，切换前后的资料库内容应当一致，不会因为统计数据缺失或者统计数据不一致而影响业务。

关于对高可用的分级在这里他们不做详细的讨论，这里只讨论常用高可用方案的优缺点以及高可用方案的选型。

主从或主主半同步复制

此种架构，一般初创企业比较常用，也便于后面步步的扩展。

通常会和proxy、keepalived等第三方软件与此同时采用，即能用来监控数据库的健康，又能执行一系列管理组织工作命令。如果主库发生故障，切换到备库后仍然能继续采用资料库。

优点：

架构比较简单，采用原生半同步复制作为统计数据同步的依据；双节点，没有主机宕机后的选主问题，直接切换即可；双节点，需求资源少，部署简单；

缺点：

完全依赖于半同步复制，如果半同步复制退化为异步复制，统计数据一致性无法得到确保；需要额外考虑haproxy、keepalived的高可用机制。

半同步复制机制是可靠的。如果半同步复制一直是生效的，那么便能认为统计数据是一致的。但由于网络波动等一些客观原因，导致半同步复制发生超时而切换为异步复制，那么这时便不能确保统计数据的一致性。所以尽可能的确保半同步复制，便可提高统计数据的一致性。

该方案同样采用双节点架构，但在原有半同复制的基础上做了功能上的优化，使半同步复制的机制变得更加可靠。

半同步复制由于发生超时后，复制断开，当再次创建起复制时，与此同时创建两条通道，其中一条半同步复制通道从当前位置开始复制，确保从机知道当前主机执行的进度。另外一条异步复制通道开始追补从机落后的统计数据。当异步复制通道追赶到半同步复制的起始位置时，恢复半同步复制。

MySQL+MHA架构

MHA现阶段在Mysql高可用方案中应该也是比较成熟和常见的方案，它由日本人合作开发出来，在mysql故障切换过程中，MHA能做到快速自动切换操作方式，而且还能最大限度保持统计数据的一致性。

MHA Manager会定时探测集群中的master节点，当master出现故障时，它能自动将最新统计数据的slave提升为新的master，然后将所有其他的slave重新指向新的master，整个故障转移过程对插件完全透明。

MHA Node运行在每台MySQL服务器上，主要就作用是切换时处理二进制日志，确保切换尽量少丢统计数据。

优点：

能展开故障的自动检测和转移;可扩展性较好，能根据需要扩展MySQL的节点数量和内部结构;相比于双节点的MySQL复制，三节点/多节点的MySQL发生不可用的概率更低

缺点：

至少需要三节点，相对于双节点需要更多的资源;逻辑较为复杂，发生故障后排查问题，定位问题更加困难;统计数据一致性仍然靠原生半同步复制确保，仍然存在统计数据不一致的风险;可能因为网络分区发生脑裂现象;

MySQL+DRDB架构

DRBD是一类基于软件、基于网络的块复制存储解决方案，主要就用作对服务器之间的磁盘、分区、逻辑卷等展开统计数据镜像，当采用者将统计数据写入本地磁盘时，还会将统计数据发送到网络中另一台主机的磁盘上，这样的本地主机(主节点)与远程主机(备节点)的统计数据就能确保实时同步。

当本地主机出现问题，远程主机上还保留着一份相同的统计数据，能继续采用，确保了数据的安全。

DRBD是linux内核模块与此同时实现的快级别的同步复制技术，能与SAN达到相同的共享存储效果。

优点：

两节点即可，部署简单，切换逻辑简单；相比于SAN储存网络，价格低廉；确保统计数据的强一致性；

缺点：

对io性能影响较大；从库不提供读操作方式；

MySQL Cluster架构

MySQL Cluster 分布式集群是Mysql官方推出的集群高可用方案，透过采用NDB存储引擎实时备份冗余统计数据，与此同时实现资料库的高可用性和统计数据一致性。

优点：

全部采用官方组件，不依赖于第三方软件；能与此同时实现统计数据的强一致性；

缺点：

国内采用的较少；配置较复杂，需要采用NDB储存引擎，与MySQL常规引擎存在很大差异；至少三节点；

MySQL Cluster 由一组计算机构成，每台计算机上均运行着多种进程，包括 MySQL服务器，NDB Cluster的统计数据节点，管理组织工作服务器，以及（可能）专门的统计数据出访程序。

由于MySQL Cluster架构复杂，部署费时（通常需要DBA几个小时的时间才能完成搭建），而依靠 MySQL Cluster Manager 只需两个命令即可完成，但 MySQL Cluster Manager 是收费的。并且业内资深人士认为NDB 不适合大多数业务场景，而且有安全问题。因此，采用的人数较少。

MySQL+MMM架构

MMM即Master-Master Replication Manager for MySQL（mysql主主复制管理组织工作器），是关于mysql主主复制配置的监控、故障转移和管理组织工作的一套可伸缩的脚本套件（在任何时候只有两个节点能被写入），这个套件也能基于标准的主从配置的任意数量的从服务器展开读负载均衡，所以你能用它来在一组居于复制的服务器启动虚拟ip，除此之外，它还有与此同时实现统计数据备份、节点之间重新同步功能的脚本。

MySQL本身没有提供replication failover的解决方案，透过MMM方案能与此同时实现服务器的故障转移，从而与此同时实现mysql的高可用。

优点：

安全、稳定性较高，可扩展性好；多主写入，无延迟复制，能确保统计数据强一致性；同样可与此同时实现读写分离有成熟的社区，有互联网公司在大规模的采用；自动故障转移，自动添加、剔除节点；

缺点：

需要为原生MySQL节点打wsrep补丁只支持innodb储存引擎至少三节点；

但在实际应用领域中，会采用多种方案的整合方案。

MySQL VS Oracle

Oracle统计数据库是甲骨文公司推出的一款亲密关系资料库信息系统，是当前资料库领域最有名、应用领域最广泛的资料库信息系统众所周知，Oracle商品覆盖了大、中、小型机等几十种机型。

Oracle资料库具有以下特点：

1、Oracle数据库可运行于绝大部分硬件平台与操作方式系统上。

2、Oracle能与多种通讯网络相连，支持多种网络协议。

3、Oracle的操作方式较为复杂，对资料库管理组织工作人员要求较高。

4、Oracle具有良好的兼容性、可移植性、可连接性和高生产率。

5、Oracle的可靠性非常高，安全可靠。

MySQL也是一款亲密关系型资料库信息系统，由MySQL AB 公司合作开发，现阶段归属于 Oracle 母公司商品，MySQL 是最盛行的亲密关系型资料库管理系统众所周知。MySQL也是一款开源的SQL资料库信息系统，是众多小型网站作为网站资料库的选择。

MySQL资料库具有以下特点：

1、MySQL是开源的，可供采用者免费采用。

2、MySQL支持多线程，充分利用CPU资源。

3、MySQL对 PHP有很好的支持，PHP是比较盛行的 Web 合作开发词汇，搭配 PHP 和 Apache 可组成良好的合作开发环境。

4、MySQL提供TCP/IP、ODBC和JDBC等多种数据库连接途径。

Oracle VS MySQL

1 统计数据安全

对于Oracle和MySQL资料库采用者来说，MySQL采用一系统的授权表来管理组织工作和跟踪采用者职权。当对采用者展开验证、授权、出访掌控时，MySQL采用这些授权表。

1.1 资料库验证

与Oracle及其他多数资料库透过采用者名和密码展开验证的机制相同，MySQL采用附加的location参数对采用者时行验证。这个location参数经查是主机名称、IP地址或者为两个通配字符串。透过这个附加的参数，MySQL能限制采用者出访域中的某些主机。更进一步能做到透过相同的主机登陆时有相同的密码和采用者职权。也就是说采用者名相同，但登陆主机的名称相与此同时，可能是相同的采用者。

1.2 职权

MySQL的职权系统是透过继承形成的分层内部结构。职权授于高层时，其他低层隐式继承被授于的职权，当然低层也可改写这些职权。

按授权范围相同，MySQL有以下种授权方式：

1、全局；

2、基于每个主机；

3、基于表；

4、基于表列。

每一级在资料库中都有两个授权表。当展开职权检查时，MySQL从高到低检查每一张表，低范围授权优先于高范围授权。

与Oracle相同，MySQL没有角色的概念。也就是说，如果对一组采用者授于同样的职权，需要对每两个采用者分别授权。

2 商业模式迁移

商业模式包含表、视图、索引、采用者、束缚、存储过程、触发器和其他资料库相关的概念。多数亲密关系型资料库都有相似的概念。

本节包含以下内容：

1、模式对象的相似性；

2、商业模式对象的名称；

4、多资料库整合；

2.1 商业模式对象的相似性

就商业模式对象，Oracle和MySQL存储诸多的相似，但也有一些相同。

2.2 商业模式对象的名称

Oracle是大小写不敏感的，并且商业模式对象是以在写时行存储。在Oracle的世界中，列、索引、存储过程、触发器以及列别名都是大小写不敏感，并且在所有的平台都是如此。MySQL是大小写敏感的，如资料库相对的存储路径、表对应的文件都是如此。

当把关键字用引号引起来时，Oracle和MySQL都允许把这些关键字用作商业模式对象。但MySQL对于一些关键字，不加引号也行。

2.3 表设计的关注点

本节主要就讨论当把MySQL转为Oracle时需要注意的地方。主要就包含以下两点：

1、字符统计数据的类型；

2、列默认值。

2.3.1 字符统计数据类型

MySQL和Oracle在字符型统计数据保存和读取上存在一些相同。MySQL的字符类型，如CHAR和VARCHAR的长度小于65535字节。Oracle支持4种字体类型：CHAR、NCHAR、NVARCHAR2和VARCHAR2。CHAR和NCHAR的最大长度为2000字节，NVARCHAR2和VARCHAR2最大长度为4000字节。

MySQL的CHAR在按很大长度存储时，是用空格填充的右对齐方式，在读取时去掉空格。

2.3.2 列默认值

MySQL会处理列默认值，不允许他为空，这点和Oracle相同。在Oracle中如果向表插入统计数据，需要对有所有不允许为NULL列的值。

2.4 多资料库迁移

如果数个MySQL资料库位于同两个资料库服务上，支持迁移。

2.5 统计数据存储概念

MySQL的资料库对应于服务器上统计数据目录内的了目录，这一统计数据存储方式与多统计数据资料库相同，也包括Oracle。资料库中的表对应两个或者数个资料库目录下的文件，并取表存储时的存储引擎。

两个Oracle资料库包含两个或者数个表空间。表空间对应统计数据在磁盘上的物理存储。表空间是从两个或者数个统计数据文件开始构建的。统计数据文件是文件系统中的文件或者原始存储的一块空间。