高性能MySQL-MySQL架构

前言

本文纪录了MySQL逻辑架构、并发控制、事务和事务特性、多版本控制等内容，并介绍了两种常用存储引擎。

MySQL逻辑架构

MySQL主要有三层组成：

第一层负责连接处理、授权认证、安全等等，并不是MySQL所独有的。
每个客户端的连接都对应着服务器上的一个线程。服务器上维护了一个线程池，避免为每个连接都创建销毁一个线程。当客户端连接到MySQL服务器时，服务器对其进行认证。可以通过用户名和密码的方式进行认证，可以通过SSL证书进行认证。登录认证过后，服务器还会验证该客户端是否具有执行某个查询的权限。
第二层负责解析查询（编译SQL），并对其进行优化（如调整表的读取顺序，选择合适的索引等）。对于SELECT语句，在解析查询之前，服务器会先检查查询缓存，如果能在其中找到对应的查询结果，则无需再进行查询解析、优化等过程，直接返回结果。存储过程、触发器、视图等都在这一层实现。
第三层是存储引擎。存储引擎负责MySQL中数据的存储和提取、开启一个事务等等。存储引擎通过API与上层进行通信，这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层的查询过程透明。存储引擎不会去解析SQL。

并发控制

无论何时，只要有多个查询需要在同一个时刻修改数据，都会产生并发控制的问题。

读写锁

在处理并发读或者写时，可以通过实现一个有两种类型的锁组成的锁系统来解决问题。这两种类型的锁通常被称为共享锁（shared lock）和排他锁（exclusive lock），也叫读锁（read lock）和写锁（write lock）。
读锁：读锁是共享的，或者说是相互不阻塞的。
写锁：写锁是排他的，也就是说一个写锁会阻塞其他的写锁和读锁。

锁粒度

一种提高共享资源并发性的方式就是让锁定对象更有选择性。尽量只锁定需要修改的部分，而不是所有资源。锁定的数据量越少，并发程度越高，只要相互之间不发生冲突即可。问题是加锁也需要消耗资源，这时就需要锁策略，就是在锁的开销和数据的安全性之间寻求平衡。每种MySQL存储引擎都可以实现自己的锁策略和锁粒度。MySQL有两种重要的锁策略表锁和行级锁。

表锁：MySQL最基本的锁策略，并且开销最小，它会锁定整张表。

行级锁：行级锁可以最大程度支持并发处理（同时也带来了最大的锁开销）。行级锁只在存储引擎层实现，而MySQL服务层没有实现。

单表加锁的命令：

格式：LOCK TABLES tbl_name {READ | WRITE},[ tbl_name {READ | WRITE},……]
例子：lock tables db_a.tbl_aaa read; 　　// 锁定了db_a库中的tbl_aaa表
解锁：unlock tables;

事务

事务内的语句，要么全部执行成功，要么全部执行失败。就像锁粒度的升级一样，事务会增加系统的开销，用来保证事务的安全性。MySQL默认采用自动提交（AUTOCOMMIT）模式，可以通过一下命令开启

mysql> show variables like 'autocommit';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | ON    |
+---------------+-------+
1 row in set (0.00 sec)mysql> set autocommit =1;

事务的特性

原子性（atomicity）：一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚，对于一个事务来说，不可能只执行其中的一部分操作。
一致性（consistency）：数据库总是从一个一致性的状态转换到另一个一致性的状态。
隔离性（isolation）：通常来说，一个事务所作的修改在最终提交之前，对其他事务时不可见的。
持久性（durability）：一旦事务提交，则其所做的修改就会永远保存到数据库。

开启事务的语句

START TRANSACTION;
insert 语句;
update 语句;
COMMIT;

事务的隔离级别

数据库事务的隔离级别有4种，由低到高分别为Read uncommitted 、Read committed 、Repeatable read 、Serializable。MySQL默认的是Repeatable read。而且，在事务的并发操作中可能会出现脏读，不可重复读，幻读。

Read uncommitted（读未提交）
事务中的修改，即使没有提交，对其他事务也是可见的。事务可以读取未提交的数据，也称脏读。在实际应用中很少使用。
例如事务A修改了账户金额，在未提交时，事务B读取了账户金额，若事务A回滚事务，事务B读取了未提交的数据，即脏读。
Read committed（读提交）
一个事务只能读取已经提交的事务所做的操作。即一个事务从开始直到提交之前，所作的任何修改对其他事务都是不可见的。
例如事务A在修改账户金额前查看了账户金额，事务B这时修改了账户金额，因为事务操作时不可见，当事务A修改金额时发现账户金额改动。出现了一个事务中两个相同查询得到不同的结果，即不可重复读。针对的是UPDATE操作。
Repeatable read（重复读）
在开始读取数据（事务开启）时，不再允许修改操作。当前事务在读取某个范围内的纪录时，另一个事务在该范围内插入了新的纪录，之前的事务再次读取该范围的纪录时，产生幻读。针对的时INSERT操作。
Serializable（序列化）
Serializable是最高的事务隔离级别，在该级别下，事务串行化顺序执行，可以避免脏读、不可重复读与幻读。Serializable会在读取的每一行数据上加锁，这种事务隔离级别效率低下，比较耗数据库性能，一般不使用。

死锁

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

数据库系统实现了各种死锁检测和死锁超时机制。

事务日志

InnoDB的事务日志主要分为redo log(重做日志，提供前滚操作)和undo log(回滚日志，提供回滚操作)，为了最大程度上减少数据写入时io问题，在存储引擎修改表的数据时，会将数据从磁盘拷贝到内存中，然后修改内存中的数据拷贝，再将修改行为持久化到磁盘中（先写redo log buffer(日志缓冲区),再定期批量写入），而不用每次将修改的数据本身持久化到硬盘中。

多版本并发控制（MVCC）

InnoDB的MVCC，通过在每行纪录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存了行的过期时间（或删除时间）。存储的并不是实际的时间值，而是系统版本号。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行纪录的版本号进行比较。在REPEATABLE READ隔离级别下，MVCC具体的操作如下：

SELECT
InnoDB会根据以下两个条件检查每行纪录：
1. InnoDB只查找版本早于当前事务版本的数据行（行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。
2. 行的删除版本，要么未定义，要么大于当前事务版本号。这样可以确保事务读取到的行，在事务开始之前未被删除。
INSERT
InnoDB为新增的每行保存当前系统版本号作为行版本号。
DELETE
InnoDB为删除的每行保存当前系统版本号作为行删除标识。
UPDATE
InnoDB为插入一行新纪录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为删除标识。

MySQL的存储引擎

MySQL默认使用InnoDB

对比项	MyISAM	InnoDB
外键	不支持	支持
事务	不支持	支持
行表锁	表锁，即使操作一条纪录也会锁住整个表，不适合高并发操作	行锁，操作时只锁定某一行，不对其他行有影响
缓存	只缓存索引，不缓存真是数据	不仅缓存索引还要缓存真实数据，对内存要求较高，而且内存大小对性能有决定行的影响
关注点	节省资源、消耗少、简单业务	并发写、事务、更大资源
默认安装	Y	Y
默认使用	Y	Y
自带系统表使用	Y	N