Mysql架构与概念
今天开始正式对《高性能Mysql》进行学习，博客主要记录学习的过程及一些认为比较重要的知识点，对于一些内容会从Mysql官网进行确认，
一、Mysql的逻辑架构
Mysql在逻辑上主要分为三部分：
- 第一部分主要用于处理客户端连接，授权认证和安全。对于Java程序来说，第一部分主要对应于MySQL Connector/J
- 第二部分主要是服务器层，包含Mysql大多数的核心服务功能，例如：查询解析、分析、优化、缓存以及所有的内置函数，所有跨存储引擎的功能都在这一层实现：存储过程、触发器、视图。
- 第三部分主要是存储引擎：存储引擎负责Mysql中数据的存储和提取。服务器通过API与存储引擎进行通信，这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层的查询过程透明。
1、连接管理与安全性
每个客户端连接都会在服务器中拥有一个线程，这个连接的查询只会在这个单独的线程中执行，该线程只能轮流在某个CPU核心或者CPU中运行。服务器会负责缓存线程，因此不需要为每一个新建的连接创建或者销毁线程。
当客户端连接到Mysql服务器时，服务器需要对其进行认证。认证基于用户名、原始主机信息和密码。一旦连接成功，服务器会继续验证该客户端是否具有执行某个特定查询的权限。
2、优化与执行
Mysql会解析查询，并创建内部数据结构（解析树），然后对其进行各种优化，包括重写查询，决定表的读取顺序，以及选择合适的索引等。用户可以通过特殊的关键字提示（hint）优化器，影响它的决策过程。也可以请求优化器解释（explain）优化过程的各个因素，使用户可以知道服务器是如何进行优化决策的，并提供一个参考基准，使用户重构查询和schema、修改相关配置，使尽可能的高效运行。
优化器并不关心底层的存储引擎，但存储引擎对优化查询是有影响的。优化器会请求存储引擎提供容量或某个具体操作的开销信息，以及表数据的统计信息。
对于SELECT语句，在解析查询之前，服务器会先检查查询缓存（Query Cache），如果能够找到对应的查询，服务器就不必再执行查询解析、优化和执行的整个过程，而是直接返回查询缓存中的结果集。
二、并发控制
1、读写锁
读锁是共享的，或者说是互不阻塞的，写锁是排他的，也就是说一个写锁会阻塞掐的写锁和读锁。
2、锁粒度
一种提高共享资源并发性的方式就是让锁定的对象更有选择性。尽量只锁定需要修改的部分数据，而不是所有的资源。更理想的方式是，只对修改的数据进行精确的锁定。任何时候，在给定的资源上，锁定的数据量越少，则系统的并发程度越高，只要相互之间不发生冲突即可。
问题是加锁也需要消耗资源，锁的各种操作，包括获得锁，检查锁是否已经解除，释放锁等，都会增加系统的开销。如果系统花费大量的时间来管理锁，而不是存取数据，那么系统的性能可能因此受到影响。
所谓的锁策略，就是在锁的开销和数据安全性之间寻求平衡。
- 表锁：表锁是Mysql中最基本的锁策略，并且是开销最小的策略。表锁会锁定整张表。
- 行级锁：行级锁可以最大成都的支持并发处理（同时也带来了最大的锁开销）。行级锁只在存储引擎层实现，而Mysql服务器层没有实现。
三、事务
在Mysql中，事务就是一组原子性的SQL查询，或者说一个独立的工作单元。如果数据库引擎能够成功的对数据库应用该组查询的全部语句，那么就执行该组查询。如果其中的任何一条语句因为崩溃或其他原因无法执行，那么所有的语句都不会执行。也就是所，事务内的语句，要么全部执行成功，要么全部执行失败。事务要满足以下四个特性：
- 原子性（atomicity）:一个事务被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚，对于一个事务来说，不可能只执行其中的一部分操作，这就是事务的原子性。
- 一致性（consistency）：数据库总是从一个一致性的状态转换到另外一个一致性的状态。
- 隔离性（isolation）：通常来说，一个事务所做的修改在最终提交以前，对其他事务是不可见的。
- 持久性（durability）：一旦事务提交，其所做的修改就会永久保存到数据库中。此时即使系统崩溃，修改的数据也不会丢失。
1、隔离级别：
- READ UNCOMMITED（未提交读）：在READ UNCOMMITED级别中，事务中的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称为脏读。
- READ COMMITED（提交读）：READ COMMITED满足前面提到的隔离性的基本定义：一个事务开始时，只能看见已经提交的事务所做的修改。换句话说，一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。这个级别有时候也叫不可重复读，因为两次执行同样的查询可能会得到不一样的结果。
- REPETABLE READ（可重复读）：REPETABLE READ解决了脏读的问题。该级别保证了同一事务中多次读取同样记录的结果是一致的。但理论上，可重复读隔离级别还无法解决另外一个幻读的问题。所谓幻读，是指当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录。
- SERILIZABLE（可串行化）：SERILIZABLE是最高的隔离级别。它通过强制事务串行执行，避免了前面说的幻读的问题。简单来说，SERILIZABLE会在读取的每一行记录上都加锁，所以可能导致大量的超时和锁争用问题。
2、死锁
死锁是指两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。当多个事务试图以不同的顺序锁定资源时，就可能会产生死锁。多个事务同时锁定一个资源时，也会产生死锁。
为了解决死锁问题，数据库系统实现了各种死锁检测和死锁超时机制。Innodb目前处理死锁的方法是，将持有最少行级排它锁的事务进行回滚。
3、事务日志
事务日志可以帮助提高事务的效率。使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝再把该修改行为记录到持久在硬盘的上的事务日志中，而不用每次都将修改的数据本身持久到磁盘。事务日志采用的是追加的方式，因此写日志的操作是磁盘上一小块区域内的顺序I/O，而不像随机I/O需要在磁盘的多个地方移动磁头，所以采用事务日志的方式相对来说要快的多。目前大多数存储引擎都是这样实现的。我们通常称之为预写式日志，修改数据需要修改两次磁盘。
如果数据的修改已经记录到事务日志中并持久化，但数据本身还没有写回磁盘，此时系统崩溃，存储引擎在重启时能够自动回复这部分修改的数据。
4、Mysql中的事务（InnoDB）
自动提交（AUTOCOMMIT）
Mysql默认采用自动提交（AUTOCOMMIT）模式。也就是说，如果不显式的开始一个事务，则每个查询都被当做一个事务提交操作。
可以通过设置AUTOCOMMIT=0来禁用自动提交模式。
隐式和显式锁定
InnoDB采用的是两阶段锁协议。在事务的执行过程中，随时都可以执行锁定，锁只有在执行COMMIT或者ROLLBACK的时候才会释放，并且所有的锁在同一时刻被释放，前面描述的锁定都是隐式锁定，InnoDB会根绝隔离级别在需要的时候自动加锁。另外，InnoDB也可以通过特定的语句进行显式锁定：
- SELECT ... LOCK IN SHARE MODE
- SELECT ... FOR UPDATE
四、多版本并发控制（MVCC）
可以认为MVCC是行级锁的一个变种，但是它在很多情况下避免了加锁操作，因此开销更低。MVCC的实现，是通过保存数据在某个时间点的快照来实现的。也就是说，不管需要执行多长的时间，每个事务看到的数据都是一致的。根据事务开始的时间不同，每个事务对同一张表，同一时刻看到的数据可能不同。
InnoDB的MVCC是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存行的过期时间（或删除时间）。当然存储的并不是实际的时间值，而是系统版本号。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号，用来和查询到的每行记录的版本号进行对比。下面看一下REPETABLE READ隔离级别下，MVCC具体是如何操作的。
SELECT
InnoDB会根据以下两个条件检索每行记录：
- InnoDB只查找版本号早于当前事务版本号的数据行（也就是，行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，要么是在事务开始之前已经存在的，要么是事务自身插入或者修改过的。
- 行的删除版本要么未定义，要么大于当前事务的版本号。这可以确保事务读取到的行，在事务开始之前未被删除。
只有符合上述两个条件的记录，才能返回作为查询结果。
INSET
InnoDB为插入的每一行保存当前西荣版本号作为行版本号
DELETE
InnoDB为删除的每一行保存当前系统版本号作为行删除标识。
UPDATE
InnoDB为插入一行新纪录，保存当前系统版本号作为行版本号，同样保存当前系统版本号到原来行作为行删除标识。
MVCC只在REPETABLE READ和READ COMMITED这两个隔离级别下工作。