本章描述了MySQL的服务器架构、各种存储引擎之间的主要区别，以及这些区别的重要性
1.1 MySQL逻辑架构
MySQL的逻辑架构如下图所示：
第一层：该层的服务并不是MySQL独有的，大多数基于网络的客户端/服务器的工具或者服务器都有类似的架构。如连接处理、授权认证、安全等
第二层：MySQL的核心服务功能层，包括查询解析、分析、优化、缓存以及所有的内置函数（如日期、时间、数学和加密函数）。所有跨存储引擎的功能都在这一层实现：存储过程、触发器、视图等。
第三层：包含了存储引擎。存储引擎负责MySQL中数据的存储和提取。
服务器通过API与存储引擎进行通信。这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层的查询过程透明。
存储引擎API包含几十个底层函数，用于执行注入“开始一个事务”或者“根据主键提取一行记录”等操作。
存储引擎不会去解析SQL，不同存储引擎之间也不会相互通信，而知简单相应上层服务器的请求。
1.1.1 连接管理与安全性
每个客户端都会在服务器中拥有一个线程，这个连接的查询只会在这单独的线程中执行，该线程只能轮流在某个CPU核心或者CPU中运行
服务器负责缓存线程，因此不需要为每一个新建的连接直接创建或者销毁线程
注：MySQL 5.5或更高的版本提供了一个API，支持线程池（Thread-Pooling）插件，可以使用池中少量的线程来服务大量的连接
当客户端（应用）连接到MySQL服务器时，服务器会基于用户名、原始主机信息和密码来进行认证，连接成功后，服务器对该客户端的权限进行判断
1.1.2 优化与执行
MySQL会解析查询，并创建内部数据结构（解析树），然后对其进行各种优化，包括重写查询、决定表的读取顺序，以及选择合适的索引等。
优化器并不关心表使用的是什么存储引擎，但存储引擎对于优化查询是有影响的
优化器会请求存储引擎提供容量或某个具体操作的开销信息，以及表数据的统计信息等。
对于select语句，在解析查询前，服务器会先检查查询缓存（Query Cache），如果能够在其中找到对应的查询，服务器就不必再执行查询解析、优化和执行的整个过程，而是直接返回查询缓存中的结果集
1.2 并发控制
无论何时，只要有多个查询需要在同一时刻修改数据，都会产生并发控制的问题
MySQL的并发控制存在于两个层面：
1. 服务器层
2. 存储引擎层
1.2.1 读写锁
在处理同一时刻的读和写操作时，可采取并发控制的方法
在处理并发读或者写时，可以通过实现一个有两种类型的锁 组成的锁系统 来解决问题
两种类型为：
1、共享锁（shared lock），也可叫读锁（read lock）
2、排他锁（exclusive lock），也可叫写锁（write lock）
锁的概念：
读锁：读锁是共享的，或者说是相互不阻塞的。多个客户在同一时刻可以同时读取同一个资源，而互不干扰
写锁：写锁时排他的，一个写锁会阻塞其他的写锁和读锁，这样可以确保在给定的时间里，只有一个用户执行写入，并防止其他用户读取正在写入的同一资源。
1.2.2 锁粒度
一种提高共享资源并发性的方式就是让锁定对象更有选择性
尽量之锁定需要修改的部分数据，而不是所有的资源。
更理想的方法是，只对会修改的数据片进行精确的锁定。任何时候，在给定的资源上，锁定的数据越少，则系统的并发程度越高，只要相互发生冲突即可。
由此会增加系统开销，导致服务器性能下降
而所谓的锁策略，就是在锁的开销和数据的安全性之间寻求平衡，而平衡也会影响到性能。
在存储引擎的设计中，锁管理是非常重要的。将锁粒度固定在某个级别，可以为某些特定的场景提供更好的性能，但会影响到其他应用场景。
MySQL支持多个存储引擎的架构，所以不需要单一的通用解决方案。
两种重要的所策略：
1、表锁（table lock）
2、行级锁（row lock）
表锁
表锁会锁定整张表，一个用户在对表进行读写操作（插入、删除、更新等）前，需先获得写锁，从而阻塞其他用户对该表的所有读写操作。
只有没有写锁时，其他读取的用户才能获得读锁，读锁之间不会相互阻塞
写锁也比读锁有更高的优先级，因此一个写锁请求可能会被插入到读锁队列的前面（写锁可以插入到锁队列中读锁的前面，反之读锁则不能插入到写锁的前面）
行级锁
行级锁可以最大程度地支持并发处理（同时也带来了最大的锁开销）。
行级锁只在存储引擎层实现，而MySQL服务器曾没有实现。服务器层完全不了解存储引擎中的锁实现。
1.3 事务
事务：一组原子性的SQL查询，或者说一个独立的工作单元。
事务内的语句，要么全部执行成功，要么全部执行失败
事务具有一个ACID的概念：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）
一个运行良好的事务处理系统，必须具备ACID特性
原子性（Atomicity）
事务的原子性：一个事务必须被视为一个不可分割的最小工作单元，事务中的操作要么全成功，要么全失败回滚，不可能只执行其中的一部分操作。
一致性（Consistency）
事务的一致性：数据库总是从一个一致性的状态，转换到另一个一致性的状态。事务没有提交时，事务中所中的修改也不会保存到数据库。
隔离性（Isolation）
通常来说，一个事务所做的修改在最终提交之前，对其他事务是不可见的。
持久性（Durability）
一旦事务提交，则其所做的修改就会永久保存到数据库中。此时及时系统崩溃，修改的数据也不会丢失。
一个解读ACID的例子：
假设一个银行的数据库有两张表，支票和储蓄，用户进行转账200元的操作时，有以下三个步骤：
1、检查支票账户中的余额高于200元
2、从支票账户余额中减去200元
3、在储蓄账户余额中增加两百元
过程包含以下5个sql语句：
1 START TRANSACTION;
2 SELECT balance FROM checking WHERE customer_id = 1234567;
3 UPDATE checking SET balance = balance - 200.00 WHERE customer_id = 1234567;
4 UPDATE savings SET balance = balance + 200.00 WHERE customer_id = 1234567;
5 COMMIT;
对于原子性，以上5个语句可组成一个事务
对于一致性，如确保了一致性，即使在执行了第三、第四条语句时出错，支票账户中也不会损失200元
对于隔离性，当执行完第三条语句、第四条语句还未开始时，此时有另一个账户汇总程序开始运行，则支票余额不会减少200元
对于持久性，一旦commit，则支票账户减少200，储蓄增加200，并永久保存在数据库中
与锁粒度的升级会增加系统开销一样，一个实现了ACID的数据库，需要更强的CPU处理能力、更大的内存和更多的磁盘空间。
用户可以根据业务是否需要事务处理，来选择合适的存储引擎，对于不需要事务的查询类应用，选择一个非事务型的存储引擎，可以获得更高的性能。
1.3.1 隔离级别
SQL标准中定义了四种隔离级别，每种级别都规定了一个事务中所做的修改，哪些在事务内和事务间可见，哪些不可见。
较低级别的隔离通常可以执行更高的并发，系统的开销也更低。
四种隔离级别如下：
READ UNCOMMITTED（未提交读）
READ COMMITTED（提交读）
REPEATABLE READ（可重复读）
SERIALIZABLE（可串行化）
READ UNCOMMITTED（未提交读）
在该级别中，事务中的修改，及时没有提交，对其他事务也都是可见的
事务可以读取未提交的数据，也被成为脏读（Dirty Read）
该级别在性能上来说，不会比其他级别好太多，但却缺乏其他级别的很多好处，在实际应用中一般很少使用
READ COMMITTED（提交读）
大多数数据库系统的默认隔离级别都是READ COMMITTED，但MySQL不是
READ COMMITTED满足前面提到的隔离性定义：一个事务开始时，只能“看见”已经提交的事务所做的修改
一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的
REPEATABLE READ（可重复读）
该隔离级别解决了脏读的问题，保证了在同一个事务中多次读取同样记录的结果是一致的。
但是理论上，该级别还是无法解决另外一个幻读(Phantom Read)的问题。
幻读：指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行（Phantom Row）。
InnoDB和XtraDB存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）解决了幻读的问题
可重复读是MySQL的默认事务隔离级别
SERIALIZABLE（可串行化）
该级别是最高的隔离级别。它通过强制事务穿行执行，避免了前面说的幻读问题
该级别会在读取的每一行数据都加锁，所以可能导致大量的超时和锁争用的问题
只有在非常需要确保数据的一致性而且可以接受没有并发的情况下，才考虑采用该级别
1.3.2 死锁
死锁是指两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。
死锁的例子：
死锁的两个解决方式：
1.存储引擎检测到死锁的循环依赖，并立即返回错误
2.当查询的时间达到锁等待超时的设定后，放弃锁请求，这种方式不太友好
InnoDB的处理方法：将持有最少行级排他锁的事务进行回滚
死锁产生的双重原因：
1.真正的数据冲突
2.存储引擎的实现方式
死锁发生后，只有部分或者完全回滚其中一个事务，才能打破死锁（事务型的系统无法避免死锁）
1.3.3 事务日志
事务日志可以帮助提高事务的效率
使用事务日志，存储引擎在修改表的数据时，只需要将修改行为记录到硬盘上的事务日志中，而不需要每次都将修改的数据本身持久化到磁盘。
事务日志持久化后，内存中被修改的数据在后台可以慢慢同步到磁盘，成为预写式日志（Write-Ahead Logging），修改数据需要些两次磁盘（修改行为和数据本身）
若在数据同步的过程，发生了系统崩溃，存储引擎在重启时能够自动回复这部分修改的数据。具体恢复方式视存储引擎而定
1.3.4 MySQL中的事务
MySQL提供了两种事务型的存储引擎：InnoDB和NDB Cluster
第三方引擎：XtraDB和PBXT，支持事务
自动提交（AUTOCOMMIT）
MySQL默认采用自动提交模式。如果不是显式开始一个事务，则每个查询都被当做一个事务执行提交操作。
启用或者禁用的操作如下图：
1：ON，表示启动 0：OFF，表示禁用
当值为0时，所有的查询都在一个事务中，直到显式执行commit提交或者rollback回滚。
修改autocommit的值，对非事务型的表（如myisam，内存表），没有任何影响，因其没有commit或者rollback的概念
当执行导致大量数据改变的操作时，如ALTER TABLE，LOCK TABLE，在执行之前会强制执行commit提交当前的活动事务
MySQL可以通过一下命令来设置隔离级别：
mysql> SET SESSION TRANSACTIONLEVEL READ COMMITTED;
MySQL能够识别所有的4个ANSI隔离级别，InooDB也支持所有隔离级别
在事务中混合使用存储引擎
MySQL服务器层不管理事务，事务是由下层的存储引擎实现的。所以在同一事务中，使用多种存储引擎是不可靠的。
如果在事务中混用了事务型和非事务型的表（如InnoDB和MyISAM表），可正常提交，但在回滚时，由于非事务型的表上的变更就无法撤销，就会导致数据库处于不一致的状态，这将会导致难以修复的后果
大多数情况下，对非事务型的操作都不会有提示
隐式和显式锁定
InnoDB采用的是两阶段锁定协议（two-phase locking protocol）：在事务执行过程中，随时都可以加锁；当执行commit或者rollback的时候才会释放，并且所有的锁是在同一时刻被释放。
在1.2.1节描述的锁都是隐式锁定，InnoDB会根据隔离级别在需要的时候自动加锁。
InnoDB也支持通过特定的语句进行显式锁定，MySQL可以显式使用LOCK TABLES和UNLOCK TABLES语句。
除了事务中禁用了AUTOCOMMIT，可以使用LOCK TABLES外，其他时候都不要显式执行LOCK TABLES。
1.4 多版本并发控制
基于提升并发性能的考虑，MySQL的大多数事务型存储引擎都事先了多版本控制（MVCC）
MVCC的实现，是通过保存数据在某个时间点的快照来实现的。
不管执行多长时间，每个事务看到的数据都是一致的
根据事务开始的时间不同，每个事务在同一张表，同一时刻看到的数据可能是不一样的
不同存储引擎的MVCC实现是不通的，典型的有乐观（optimistic）并发控制和悲观（pessimistic）并发控制
InnoDB的MVCC，是通过在每行记录后面保存有两个隐藏的列来实现的。一个保存了行的创建时间，一个保存了行的过期时间
存储的是系统版本号（system version number），而不是实际的时间值
每开始一个新的事务，系统版本号都会递增
事务开始时刻的系统版本号会作为事务的版本号，用来查询到的每行记录的版本号进行比较
在REPEATABLE READ隔离级别下，MVCC的具体操作：
SELECT
InnoDB会根据一下两个条件查询每行记录：
a. InnoDB只查找版本早于当前事务版本的数据行（也就是，行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取到的行，要么是在事务开始之前已经存在，要么是事务自身插入或者修改过的
b. 行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除。
只有符合上述两个条件的记录，才能返回查询结果
INSERT
InnoDB为新插入的每一行保存当前系统版本号作为行版本号
DELETE
InnoDB为删除的每一行保存当前系统版本号作为行删除标识
UPDATE
InnoDB为插入的每一行新纪录，保存当前系统版本号作为行版本号，同事保存当前系统版本号到原来的行作为行删除标识
保存这两个系统版本号，使大多数操作都可以不用加锁
这样的设计使得读数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行
不足之处：需要额外存储空间，需要做更多的行检查工作
MVCC只在REPEATABLE READ 和 READ COMMITTED两个隔离级别下工作，而不兼容其他两个隔离级别，因为READ UNCOMMITTED总是读取最新的数据行，而不是符合当前事务版本的数据行，而SERIALZABLE则会对所有读取的行都加锁