MySQL读书学习笔记（一）——架构

MySQL最与众不同的特性是他的存储引擎架构，这种架构的设计将查询处理（Query Processing）及其他系统任务和数据存储、提取相分离。这种处理和存储分离的设计可以在使用时根据性能、特性，以及其他需求来选择数据存储的方式。

1.1 MySQL逻辑架构

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），也叫读锁和写锁。

读锁是共享的，或者说是相互不阻塞的。多个客户在同一时刻可以同时读取同一个资源，而互不干扰。写锁则是排他的，也就是说一个写锁会阻塞其他读锁和写锁，出于安全考虑。

1.2.2 锁粒度

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

问题是加锁也会消耗资源。锁的各种操作，包括获得锁、检查锁是否已经解除、释放锁等，都会增加系统的开销。如果系统花费大量时间来管理锁，而不是存取数据，那么系统的性能可能会受到影响。

所谓的锁策略，就是在锁的开销与数据的安全性之间寻求平衡，这种平衡当然也会影响到性能。大多数商业数据库没有提供更多的选择，一般都是在表上施加行级锁。并以各种复杂的方式来实现，以便在锁比较多的情况下尽量提供更好的性能。

表锁（table lock）

表锁是MySQL中最基本的锁策略，并且是开销最小的策略。一个用户在对表进行写操作前，需要先获得写锁，这会阻塞其他用户对该表的读写操作。只有没有写锁时，其他的用户才能获得读锁，读锁之间是不相互阻塞的。

在特定的场景中，表锁也能具有良好的性能。

尽管存储引擎可以管理自己的锁，MySQL本身还是会使用各种有效的表锁来实现不同的目的。

行级锁（row lock）

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

1.3 事务

事务必须具有ACID的特征。

原子性（atomicity）

一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚，对一个事务来说，不可能只执行其中的一部分操作，这就是事务的原子性。

一致性（consistency）

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

隔离性（isolation）

通常来说，一个事务所做的修改在最终提交以前，对其他事务是不可见的。

持久性（durability）

一旦事务提交，则其所做的修改就会永久保存到数据库中。此时即使系统崩溃，修改的数据也不会丢失。持久性是个模糊的概念，因为持久性有很多不同的级别。有些持久性策略能够提供非常强的安全保障，而有些则未必。而且没有100%持久性保证的策略。

1.3.1 隔离级别

READ UNCOMMITTED（未提交读）

在此级别，事务中的修改，即使没有提交，对其他事务也是可见的。事务可以读取未提交的数据，这被称之为脏读（Dirty Read）。这个级别会导致很多问题，从性能上来说，它不会比其他级别好太多，但却缺乏很多好处，除非很有必要，不然不应使用。

READ COMMITTED（提交读）

大多数数据库系统的默认隔离级别（MySQL不是）。它满足隔离性的简单定义：一个事务开始时，只能看见已提交的事务所做的修改。也就是说一个事务从开始到提交之前，所做的任何修改对其他事务都是不可见的。这个级别也叫不可重复读，因为两次执行同样的查询，可能会得到不一样结果。

REPEATABLE READ（重复读）

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

可重复读是MySQL的默认事务隔离级别。

SERIALIZABLE（可串行化）

最高的隔离级别。它通过强制事务串行执行，避免了幻读问题。在读取的每一行数据上都加锁，所以可能导致大量的超时和锁争用的问题。实际应用中也很少用到，只有在非常需要数据一致而且没有并发的情况下，才考虑采用该级别。

1.3.2 死锁

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

InnoDB目前处理死锁的方法是，将持有最少行级排它锁的事务进行回滚。

1.3.3 事务日志

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

1.3.4 MySQL中的事务

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

自动提交（AUTOCOMMIT）

MySQL默认采用自动提交模式，如果不是显式地开始一个事务，则每个查询都被当作一个事务提交操作。

在事务中混合使用存储引擎

MySQL服务器层不管理事务，事务是由下层的存储引擎实现的。所以在同一个事务中，使用多种存储引擎是不可靠的。

隐式和显式锁定

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

1.4 多版本并发控制（MVCC）

MySQL大多数存储引擎实现的都不是简单额行级锁。基于提升并发性能的考虑，他们一般都实现了MVCC。Oracle, PostgreSQL等其他数据库系统也都实现了，只是实现机制不尽相同，因为MVCC没有一个统一的实现标准。

可以认为MVCC是行级锁的一个变种，但它在很多情况下避免了加锁操作，因此开销更低。虽然实现机制有所不同，但大多都实现了非阻塞的读操作，写操作也只锁定必要的行。

MVCC的实现，是通过保存数据在某个时间点的快照来实现的。也就是说，不管需要执行多长时间，每个事务看到的数据都是一致的，根据事务开始的时间不同，每个事务对同一张表，同一时刻看到的数据可能是不一样的。

1.5 MySQL存储引擎

在文件系统中，MySQL将每个数据库（schema）保存为数据目录下的一个子目录。创建表时，MySQL会在数据库子目录下创建一个和表同名的.frm文件保存表的定义。在Windows中，大小写不敏感；而在类Unix中则是敏感的。不同的存储引擎保存和索引数据的方式是不同的，但表的定义则是在MySQL服务层统一处理的。

1.5.1 InnoDB存储引擎

InnoDB是MySQL默认事务型引擎，也是最重要，使用最广泛的存储引擎。它被用来处理大量的短期事务，短期事务大部分是正常提交的，很少回滚。InnoDB的性能和自动崩溃恢复特性，使得它在非事务性存储的需求中也很流行。除非有特别原因使用其他引擎，否则应优先考虑InnoDB。

1.5.2 MyISAM引擎

MyISAM提供了大量的特性，包括全文索引，压缩，空间函数等，但不支持事务和行级锁，而且有一个毫无疑问的缺陷就是崩溃后无法恢复。对于只读的数据，或者表比较小，可以忍受修复，则可以使用（但默认使用InnoDB）。

1.5.3 选择合适的引擎

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

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