《高性能MySQL》MySQL架构与历史

MySQL架构与历史

MySQL最与众不同的特性是它的存储引擎架构，这种架构的设计将查询处理（Query Processing）及其他系统任务（Server Task）和数据的存储/提取相分离。

1.1逻辑架构

 

 

 

最上层的服务并不是MySQL所独有的，大多数基于网络的客户端/服务器的工具或者服务都有类似的架构。比如连接处理、授权认证、安全等等。

第二层架构是MySQL比较有意思的部分。大多数MySQL的核心服务功能都做这一层，包括查询简析、分析、优化、缓存以及所有的内置函数，所有跨存储引擎的功能都在这一层实现：存储过程、触发器、视图等。

第三层包含了存储引擎。存储引擎负责MySQL中数据的存储和提取。和GNU/Linux下的各种文件系统一样，每个存储引擎都有的它的优势和劣势。服务器通过API与存储引擎进行通信。这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层的查询过程透明。存储引擎API包含了几十个底层函数，用于执行诸如“开始一个事务”或者“根据主键提取一行记录”等操作。但不同存储引擎不会解析SQL，不同存储引擎也不会相互通信，而只是简单地响应上层服务器的请求。

1.1.1连接管理与安全性

每个客户端连接都会在服务器进程中拥有一个线程，这个连接的查询只会在这个单独的线程中执行，该线程只能轮流在某个CPU核心或者CPU中进行。服务器会负责缓存线程，因此不需要为每一个新建的连接创建或者销毁线程。

当客户端连接到MySQL服务器时，服务器需要对其进行认证。认证基于用户名、原始主机信息和密码。如果使用了安全套接字（SSL）的方式连接，还可以使用X.509证书认证。一旦客户端连接成功，服务器会继续验证该客户端是否具有执行某个特定查询的权限。

1.1.2优化与执行

MySQL会解析查询，并创建内部结构数据（解析树），然后对其进行各种优化，包括重写查询、决定表的读取顺序，以及选择合适的索引等。

优化器并不关心表使用的是什么存储引擎，但存储引擎对于优化查询是有影响的。优化器会请求存储引擎提供容量或某个具体操作的开销信息，以及表数据的统计信息等。

对于SELECT语句，在解析查询之前，服务器会先检查查询缓存（Query Cache），如果能够在其中找到对应的查询，服务器就不必再执行查询解析、优化和执行的整个过程，而是直接返回查询缓存中的结果集。

1.2并发控制

1.2.1读写锁

两种锁：共享锁（shared lock）和排他锁（exclusive lock），也叫读锁（read lock）和写锁（write lock）。

读锁是共享的，或者说是相互不阻塞的。多个客户在同一时刻可以同时读取同一个资源，而互不干扰。写锁则是排他的，也就是说一个写锁会阻塞其他的写锁和读锁，这是出于安全策略的考虑，只有这样才能确保在给定的时间里，只有一个用户执行写入，并防止其他用户读取正在写入的同一资源。

1.2.2锁粒度

一种提高共享资源并发性的方式就是让锁定对象更有选择性。尽量只锁定需要修改的部分数据，而不是所有的资源。更理想的方式是，只对会修改的数据片进行精确的锁定。任何时候，在给定的资源上，锁定的数据量越少，则系统的并发程度越高，只要相互之间不发生冲突即可。

问题是加锁也需要消耗资源。锁的各种操作，包括获得锁、检查锁是否已经解除、释放锁等，都会增加系统的开销。如果系统花费大量的时间来管理锁，而不是存取数据，那么系统的性能可能会因此受到影响。大多数情况下，一般都是在表上施加行级锁（row level lock）。

表锁（table lock）

表锁是MySQL中最基本的锁策略，并且是开销最小的策略。

行级锁（row lock）

行级锁可以最大程度地支持并发处理（同时也带来了最大的锁开销）。众所周知，在InnoDB和XtraDB，以及其他一些存储引擎中实现了行级锁。行级锁只存在存储引擎层实现，而MySQL服务器层没有实现。

1.3事务

事务ACID特性：原子性（atomicity）、一致性（consistency）、隔离性（isolation）、持久性（durability）

对于一些不需要事务的查询类应用，选择一个非事务型的存储引擎，可以获得更高的性能。及时存储引擎不支持事务，也可以通过LOCK TABLE语句为应用提供一定程度的保护，这些选择用户都可以自主决定。

1.3.1隔离级别

READ UNCOMMITTED（未提交读）

在READ UNCOMMITTED级别，事务中的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称为脏读。这个级别会导致很多问题，从性能上来说，READ UNCOMMITTED不会比其他的级别好太多，但却缺乏其他级别的很多好处，除非真的有非常必要的理由，在实际应用中一般很少使用。

READ COMMITTED（提交读）

大多数数据库系统默认隔离级别都是READ COMMITTED（但MySQL不是）。READ COMMITTED：一个事务开始时，只能“看见”已提交的事务所做的修改。换句话说，一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。这个级别有时候也叫不可重读读，因为两次执行相同的查询，可能会得到不一样的结果。

REPEATABLE READ（可重复读）

REPEATABLE READ（MySQL默认的事务隔离级别）解决了脏读的问题。该级别保证了在同一个事务中多次读取同样的记录的结果是一致的。理论上，可重复读隔离级别还是无法解决另外一个幻读的问题。所谓幻读，指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行。InnoDB和XtraDB存储引擎通过多版本并发控制（MBCC）解决了幻读的问题。

SERIALIZABLE（可串行化）

SERIALIZABLE是最高的隔离级别。它通过强制事务串行执行，避免了前面说的幻读的问题。

隔离级别	脏读可能性	不可重复读可能性	幻读可能性	加锁读
READ UNCOMMITTED	Y	Y	Y	N
READ COMMITTED	N	Y	Y	N
REPEATABLE READ	N	N	Y	N
SERIALIZABLE	N	N	N	Y

 

 

 

 

不可重复读与幻读的区别：幻读是指读到了其他已经提交事务的新增数据，而不可重复读是指读到了已经提交事务的更新数据（update/delete），为了避免这两种情况，采取的决策是不同的，防止读取到更新数据，只需要对操作的数据添加行级锁就可。

1.3.2死锁

死锁是指两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。当多个事务试图以不同的顺序锁定资源时，就可能产生死锁。

为了解决这种问题，数据库系统实现了各种死锁检测和死锁超时机制。约复杂的系统，比如InnoDB存储引擎，越能检测到死锁的循环依赖，并理解返回一个错误。这种解决方式很有效，否则死锁会导致出现非常慢的查询。还有一种解决方式，就是当查询的时候达到锁等待超时的设定后放弃锁请求，这种方式通常来说不太好。InnoDB目前处理死锁的方法是，将持有最少行级排他锁的事务进行回滚。

锁的行为和顺序是和存储引擎相关的。以同样的顺序执行语句，有些存储引擎会产生死锁，有些则不会。死锁的产生有双重原因：有些是因为真正的数据冲突，这种情况通常很难避免，但有些则完全是由于存储引擎的实现方式导致的。

 1.3.3事务日志

事务日志可以帮助提高事务的效率。使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据本身持久化到磁盘。事务日志采用的是追加的方式，因此写日志的操作是磁盘上一小块区域的顺序I/O，而不像随机I/O需要在磁盘的多个地方移动刺头，所以采用事务日志的方式相对来说要快的多。事务日志持久化以后，内存中被修改的数据在后台可以慢慢的刷回到磁盘。目前大多数存储引擎都是这样实现的，我们通常称之为预写式日志，修改数据需要写两次磁盘。

如果数据的修改已经记录到事务日志并持久化，但数据本身还没有写回磁盘，此时系统崩溃，存储引擎在重启时能够自动恢复这部分修改的数据。具体的恢复方式则视存储引擎而定。

1.3.4MySQL中的事务

MySQL提供了两种事务型的存储引擎：InnoDB和NDB Cluster。另外还有一些第三方存储引擎也支持事务，比较知名的XtraDB和PBXT。

自动提交（AUTOCOMMIT）

MySQL默认采用自动提交（AUTOCOMMIT）模式。也就是说，如果不是显式地开始一个事务，则每个查询都背当做一个事务执行提交操作。

MySQL可以通过SET TRANSACTION ISOLATION LEVEL命令来设置隔离级别。新的隔离级别会再下一个事务开始的时候生效。可以在配置文件中设置整个数据库的隔离级别，也可以只改变当前会话的隔离级别：

mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED

 

MySQL能够识别所有的4个ANSI隔离级别，InnoDB引擎也支持所有的隔离级别。

隐式和显式锁定

InnoDB采用的是两阶段锁定协议。在事务执行过程中，随时都可以执行锁定，锁只是在执行COMMIT或者ROLLBACK的时候才会释放，并且所有的锁是在同一时刻被释放。前面描述的锁定都是隐式锁定，InnoDB会根据隔离级别在需要的时候自动加锁。 

1.4多版本并发控制

MySQL的大多数事务型存储引擎实现的都不是简单的行级锁。基于提升并发性能的考虑，它们一般都同时实现了多版本并发控制（MVCC）。不仅是MySQL，包括Oracle。可以认为MVCC是行级锁的一个变种，但是它在很多情况下避免了加锁操作，因此开销更低。虽然实现机制有所不同，但大都实现了非阻塞的读操作，写操作也只锁定必要的行。

MVCC的实现，是通过保存数据在某个时间点的快照来实现的。InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存行的过期时间（或删除时间）。当然存储的并不是实际的时间值，二十系统版本号。每开始一个新的事务，系统版本号都会自动递增。系统开始时刻的版本号会作为事务的版本号，用来查询到的每行记录的版本号进行比较。

MVCC只在REPEATABLE READ和READ COMMITTED两个级别下工作。其他两个隔离级别都和MVCC不兼容，因为READ UNCOMMITTED总是读取最新的数据行，而不是符合当前事务版本的数据行。而SERIALIZABLE则会对所有读取的行都加锁。

1.5MySQL的存储引擎

在文件系统中，MySQL将每个数据库（也可以称之为schema）保存为数据目录下的一个子目录。创建表时，MySQL会再数据库子目录下创建一个和表同名的.frm文件保存表的定义。因为MySQL使用文件系统的目录和文件来保存数据库和表的定义，大小写敏感和具体的平台密切相关。在Windows中，大小写不敏感；而在Unix中则是敏感的。不同存储引擎保存数据和索引的方式是不同的，单表的定义则是在MySQL服务层同一处理的。 

1.5.1InnoDB存储引擎

 InnoDB是MySQL默认的事务型引擎，也是最重要、使用最广泛的存储引擎。它被设计用来处理大量的短期事务，短期事务大部分情况是正常提交的，很少会被回滚。InnoDB的性能和自动崩溃恢复特性，使得它在非事务型存储的需求中也很流行。

InnoDB采用MVCC来支持高并发，并且实现了四个标准的隔离级别。默认级别是REPEATABLE READ（可重复读），并且通过间歇锁（next-key locking）策略防止幻读的出现。间歇锁使得InnoDB不仅仅锁定查询涉及的行，还会对索引中的间歇进行锁定，以防止幻影行的出现。

InnoDB表是基于聚簇索引建立的。聚簇索引对主键查询有很高的性能。不过它的二级索引中必须包含主键列，所以如果主键列很大的话，其他的所有索引都会很大。因此，若表上的索引较多的话，主键应当尽可能的小。

InnoDB内部做了很多优化包括从磁盘读取数据时采用可预测性预读，能够自动在内存中创建hash索引以加速读操作的自适应哈希索引，以及能够加速插入操作的插入缓存区（insert buffer）等。【补充资料：InnoDB官方手册中的InnoDB事务模型和锁】

作为事务型的存储引擎，InnoDB通过一些机制和工具支持真正的热备份。MySQL的其他存储引擎不支持热备份，要获取一致性视图需要停止对所有表的写入，而在读写混合场景中，停止写入可能也意味着停止读取。

1.5.2MyISAM存储引擎

在MySQL 5.1及之前的版本，MyISAM是默认的存储引擎。MyISAM提供大量的特性，包括全文索引、压缩、空间函数（GIS）等，但MyISAM不支持事务和行级锁，而且有一个毫无疑问的缺陷就是崩溃后无法安全检查。对于只读的数据，或者表比较小，可以忍受修复操作，则依然可以继续使用MyISAM。

存储

MyISAM会将表存储在两个文件中：数据文件和索引文件，分别以.MTD和.MYI为扩展名。MyISAM表可以存储的行记录数，一般受限于可用的磁盘空间，或者操作系统中单个文件的最大尺寸。

MyISAM特性

1.加锁与并发

　　MyISAM对整张表加锁，而不是针对行。读取时会对需要读到的所有表加共享锁，写入时则对表加排他锁。但是在表有读取数据时，可以往表中插入新的记录（并发插入）。

2.修复

　　对于MyISAM表，MySQL可以手工或者自动执行检查和修复操作，但这里说的修复和事务恢复以及崩溃恢复是不同的概念。执行表的修复可能导致一些数据丢失，而且修复操作是非常慢的。可以通过CHECK TABLE XXX检查表的错误，如果有错误可以通过REPAIR TABLE XXX进行修复。

3.索引特性

　　对于MyISAM表，即使是BLOB和TEXT等长字段，也可以基于前500个字符创建索引。MyISAM支持全文索引，这是一种基于分词创建的索引，可以支持复杂的查询。

4.延迟更新索引键

　　创建MyISAM表的时候，如果指定了DELAY_KEY_WRITE选项，在每次修改执行完成时，不会立刻将修改的索引数据写入磁盘，而是会写到内存中的捡缓冲区，只有在清理键缓冲区或者关闭表的时候才会将对应的索引块写入到磁盘。这种方式可以极大地提升写入性能，但是在数据库或者主机崩溃时会造成索引损坏，需要执行修复操作。

MyISAM压缩表

如果表在创建并导入数据之后，不会再进行修改操作，那么这样的表或许是和采用MyISAM压缩表。

可以使用myisampack对MyISAM表进行压缩（也叫打包pack）。压缩表是不能进行修改的（除非先将表解除压缩，修改数据，然后再次压缩）。压缩表可以极大地减少磁盘空间占用，因此也可以减少磁盘I/O，从而提高查询性能。压缩表也支持索引，但索引是只读的。

MyISAM性能

MyISAM引擎设计简单，数据以紧密格式存储，所以某些场景下的性能很好。MyISAM有一些服务器级别的性能扩展限制，比如对索引键缓冲区的Mutex锁，MariaDB基于段的索引键缓冲区机制来避免该问题。但MyISAM最典型的性能问题还是表锁的问题，如果你发现所有的查询都长期处于“Locked”状态，那么毫无疑问表锁是罪魁祸首。

1.5.3MySQL内建的其他存储引擎

 

1.5.4第三方存储引擎

 

1.5.5选择合适的引擎

除非需要用到某些InnoDB不具备的特性，并且没有其他办法可以替代，否则都应该优先选择InnoDB引擎。

除非万不得已，否则建议不要混合使用多种存储引擎，否则可能带来一些列复杂的问题，以及一些潜在的bug和边界问题，至少混合储存对一致性备份和服务器参数配置带来了一些困难。

 大数据量

 什么样的数据量算大？我们创建或者管理的很多InnoDB数据库的数据量在3~5TB之间，或者更大，这是单台机器上的量，不是一个分片的量。这些系统运行得还不错，要做到这一点需要合理地选择硬件，做好物理设计，并为服务器的I/O瓶颈做好规划。在这样的数据量下，如果采用MyISAM，崩溃后的恢复就是一个噩梦。

如果数据量继续增长到10TB以上的级别，可能就需要建立数据仓库。Infobright是MySQL数据仓库最成功的解决方案。也是一些大数据库不适合Infobright，却可能适合TokuDB。

1.5.6转换表的引擎

 三种转换表引擎的方法

　　①.ALTER TABLE，最简单的方法

　　mysql> ALTER TABLE mytable ENGINE = InnoDB;

　　最简单，但有一个问题：需要执行很长时间。MySQL会执行将数据从元彪复制到一张新表中，在复制期间可能会消耗系统所有的I/O能力，同事原表会加上读锁。所以，在繁忙的表上执行此操作要特别小心。如果转换表的引擎，将会失去和原引擎相关的所有特性。例如，如果将一张InnoDB表转换为MyISAM，然后再转换回InnoDB，原InnoDB表上所有的外键将丢失

　　②.导出与导入

　　使用mysqldump工具将数据导出到文件，然后修改文件导入。

　　③.创建与查询（CREATE 和 SELECT）

　　第一步：创建一张新表

　　第二步：insert into XXX select * from XXX

　　如果数据量特别大的话，可以分批操作

1.6时间线（Timeline）

 

1.7MySQL的开发模式

 

1.8总结