MySQL 原理

1.MySQL基础

MySQL 是一个开放源代码的关系数据库管理系统。原开发者为瑞典的 MySQL AB 公司，最早是在 2001 年 MySQL3.23 进入到管理员的视野并在之后获得广泛的应用。 2008 年 MySQL 公司被 Sun 公司收购并发布了首个收购之后的版本 MySQL5.1，该版本引入分区、基于行复制以及 plugin API。移除了原有的 BerkeyDB 引擎，同时，Oracle收购 InnoDB Oy 发布了 InnoDB plugin，这后来发展成为著名的 InnoDB 引擎。2010 年 Oracle 收购 Sun 公司，这也使得 MySQL 归入 Oracle 门下，之后 Oracle 发布了收购以后的首个版本 5.5，该版本主要改善集中在性能、扩展性、复制、分区以及对 windows 的支持。目前版本已发展到 5.7。

和其它数据库相比，MySQL 有点与众不同，它的架构可以在多种不同场景中应用并发挥良好作用。主要体现在存储引擎的架构上，插件式的存储引擎架构将查询处理和其它的系统任务以及数据的存储提取相分离。这种架构可以根据业务的需求和实际需要选择合适的存储引擎。

2.MySQL 逻辑架构

1.最上层是一些客户端和连接服务，包含本地 sock 通信和大多数基于客户端/服务端工具实现的类似于 tcp/ip 的通信。主要完成一些类似于连接处理、授权认证、及相关的安全方案。在该层上引入了线程池的概念，为通过认证安全接入的客户端提供线程。同样在该层上可以实现基于 SSL 的安全链接。服务器也会为安全接入的每个客户端验证它所具有的操作权限。

2.第二层架构主要完成大多少的核心服务功能，如 SQL 接口，并完成缓存的查询，SQL 的分析和优化及部分内置函数的执行。所有跨存储引擎的功能也在这一层实现，如过程、函数等。在该层，服务器会解析查询并创建相应的内部解析树，并对其完成相应的优化如确定查询表的顺序，是否利用索引等，最后生成相应的执行操作。如果是 select 语句，服务器还会查询内部的缓存。如果缓存空间足够大，这样在解决大量读操作的环境中能够很好的提升系统的性能。

3.存储引擎层，存储引擎真正的负责了 MySQL 中数据的存储和提取，服务器通过 API 与存储引擎进行通信。不同的存储引擎具有的功能不同，这样我们可以根据自己的实际需要进行选取。

4.数据存储层，主要是将数据存储在运行于裸设备的文件系统之上，并完成与存储引擎的交互。

3.并发控制和锁的概念

当数据库中有多个操作需要修改同一数据时，不可避免的会产生数据的脏读。这时就需要数据库具有良好的并发控制能力，这一切在 MySQL 中都是由服务器和存储引擎来实现的。

解决并发问题最有效的方案是引入了锁的机制，锁在功能上分为共享锁(shared lock)和排它锁(exclusive lock)即通常说的读锁和写锁。当一个 select 语句在执行时可以施加读锁，这样就可以允许其它的 select 操作进行，因为在这个过程中数据信息是不会被改变的这样就能够提高数据库的运行效率。当需要对数据更新时，就需要施加写锁了，不在允许其它的操作进行，以免产生数据的脏读和幻读。锁同样有粒度大小，有表级锁(table lock)和行级锁(row lock)，分别在数据操作的过程中完成行的锁定和表的锁定。这些根据不同的存储引擎所具有的特性也是不一样的。

MySQL 大多数事务型的存储引擎都不是简单的行级锁，基于性能的考虑，他们一般都同时实现了多版本并发控制(MVCC)。这一方案也被 Oracle 等主流的关系数据库采用。它是通过保存数据中某个时间点的快照来实现的，这样就保证了每个事务看到的数据都是一致的。详细的实现原理可以参考《高性能 MySQL》第三版。

4.事务

1.简单的说事务就是一组原子性的 SQL 语句。可以将这组语句理解成一个工作单元，要么全部执行要么都不执行。在 MySQL 中可以使用如下命令操作事务：

注意：默认 MySQL 中自动提交是开启的：

2.事务具有 ACID 的特性：

原子性(atomicity):事务中的所有操作要么全部提交成功，要么全部失败回滚。

一致性(consistency):数据库总是从一个一致性状态转换到另一个一致性状态。

隔离性(isolation):一个事务所做的修改在提交之前对其它事务是不可见的。

持久性(durability):一旦事务提交，其所做的修改便会永久保存在数据库中。

3.事务的隔离级别：在 SQL 标准中定义了四种隔离级别：

READ UNCOMMITTED(读未提交)：事务中的修改即使未提交也是对其它事务可见

READ COMMITTED(读提交)：事务提交后所做的修改才会被另一个事务看见，可能产生一个事务中两次查询的结果不同。

REPEATABLE READ(可重读)：只有当前事务提交才能看见另一个事务的修改结果。解决了一个事务中两次查询的结果不同的问题。

SERIALIZABLE(串行化)：只有一个事务提交之后才会执行另一个事务。

4.MySQL 中可以利用如下语句查询并临时修改隔离级别：

5.死锁：两个或多个事务在同一资源上相互占用并请求锁定对方占用的资源，从而导致恶性循环的现象。MySQL 的部分存储引擎能够检测到死锁的循环依赖并产生相应的错误。InnoDB 引擎解决死锁的方案是将持有最少排它锁的事务进行回滚。

5.MySQL 存储引擎及应用方案

1.MySQL 采用插件式的存储引擎架构，可以根据不同的需求为不同的表设置不同的存储引擎。可以通过如下命令显示数据库中表的状态信息，以 user 表为例，显示如下：

Name：显示的是表名

Engine：显示存储引擎，该表存储引擎为 MyISAM

Row_format：显示行格式，对于 MyISAM 有 Dynamic、Fixed 和 Compressed 三种。非别表示表中有可变的数据类型，表中数据类型为固定的，以及表是压缩表的环境。

Rows：显示表中行数

Avg_row_length：平均行长度（字节）

Data_length：数据长度（字节）

Max_data_length：最大存储数据长度（字节）

Data_free：已分配但未使用的空间，包括删除数据空余出来的空间

Auto_increment：下一个插入行自动增长字段的值

Create_time：表的创建时间

Update_time：表数据的最后修改时间

Collation：表的默认字符集及排序规则

Checksum：如果启用，表示整个表的实时校验和

Create_options：创建表示的一些其它选项

Comment：额外的一些注释信息，根据存储引擎的不同表示的内容也不胫相同。

2.存储引擎介绍：

InnoDB 引擎：

1.将数据存储在表空间中，表空间由一系列的数据文件组成，由 InnoDB 管理；

2.支持每个表的数据和索引存放在单独文件中(innodb_file_per_table)；

3.支持事务，采用 MVCC 来控制并发，并实现标准的 4 个事务隔离级别，支持外键；

4.索引基于聚簇索引建立，对于主键查询有较高性能；

5.数据文件的平台无关性，支持数据在不同的架构平台移植；

6.能够通过一些工具支持真正的热备。如 XtraBackup 等；

7.内部进行自身优化如采取可预测性预读，能够自动在内存中创建 hash 索引等。

MyISAM 引擎：

1.MySQL5.1 中默认，不支持事务和行级锁；

2.提供大量特性如全文索引、空间函数、压缩、延迟更新等；

3.数据库故障后，安全恢复性差；

4.对于只读数据可以忍受故障恢复，MyISAM 依然非常适用；

5.日志服务器的场景也比较适用，只需插入和数据读取操作；

6.不支持单表一个文件，会将所有的数据和索引内容分别存在两个文件中；

7.MyISAM 对整张表加锁而不是对行，所以不适用写操作比较多的场景；

8.支持索引缓存不支持数据缓存。

Archive 引擎：

1.只支持 insert 和 select 操作；

2.缓存所有的写数据并进行压缩存储，支持行级锁但不支持事务；

3.适合高速插入和数据压缩，减少 IO 操作，适用于日志记录和归档服务器。

Blackhole 引擎：

1.没有实现任何存储机制，会将插入的数据进行丢弃，但会存储二进制日志；

2.会在一些特殊需要的复制架构的环境中使用。

CSV 引擎：

1.可以打开 CSV 文件存储的数据，可以将存储的数据导出，并利用 excel 打开；

2.可以作为一种数据交换的机制，同样经常使用。

3.第三方存储引擎：

1.OLTP 类：

XtraDB：InnoDB 的改进版本。

PBXT：类似 InnoDB，但提供引擎级别的复制和外键约束，适当支持 SSD 存储。

TokuDB(开源)：支持分形树索引结构，支持海量数据的分析。

2.列式存储引擎：MySQL默认是面向行的存储

Infobright: 支持数十 TB 的数据量，为数据分析和数据仓库设计的。数据高度压缩。

InfiniDB:可以在一组集群间做分布式查询，有商业版但没有典型应用案例。

3.社区存储引擎：

Aria：解决 MyISAM 崩溃安全恢复问题，并能够进行数据缓存。

Groona: 全文索引引擎。

QQGraph: 由 Open query 研发支持图操作，比如查找两点间最短距离。

SphinxSE: 该引擎为 Sphinx 全文索引搜索服务器提供 SQL 接口。

Spider: 支持 sharding 并能够基于分片实现并列查询。

VPForMySQL: 支持垂直分区。

4.存储引擎选取参考因素

1.是否有事务需求

如果需要事务支持最好选择 InnoDB 或者 XtraDB，如果主要是 select 和 insert 操作 MyISAM 比较合适，一般使用日志型的应用。

2.备份操作需求

如果能够关闭服务器进行备份，那么该因素可以忽略，如果需要在线进行热备份，则 InnoDB 引擎是一个不错的选择。

3.故障恢复需求

在对恢复要求比较好的场景中推荐使用 InnoDB，因为 MyISAM 数据损坏概率比较大而且恢复速度比较慢。

4.性能上的需求

有些业务需求只有某些特定的存储引擎才能够满足，如地理空间索引也只有 MyISAM 引擎支持。所以在应用架构需求环境中也需要管理员折衷考虑，当然从各方面比较而言，InnoDB 引擎还是默认应该被推荐使用的。

5.表引擎转换方法

1.直接修改

2.备份修改

利用 mysqldump 备份工具将数据导出，修改 create table 语句中的存储引擎选项。注意修改的同时修改表名。

3.创建插入