1.1 MySQL逻辑架构
- 最上层的服务并不是MySQL所独有的，大多数基于网络的客户端/服务器的工具或者服务都有类似的架构，比如连接处理、授权处理、安全等等
- 第二次架构是MySQL的核心服务功能所在，包括查询解析、分析、优化、缓存以及所有的内置函数（例如：日期、时间、数学加密函数），所有跨存储引擎的功能都在这一层实现：存储过程、触发器、视图
- 第三层包含了存储引擎。存储引擎负责MySQL数据的存储和提取，服务器通过API于存储引擎进行通信。这些接口屏蔽了不同存储引擎之间的差异。存储引擎API包含几十个底层函数，用于执行诸如”开始一个事务“或者”根据主键提取一行记录“等操作。但存储器不会去解析SQL，不同存储引擎之间也不会通信，只是简单的响应上层服务器的请求。
1.1.1 连接管理与安全性
每个客户端链接都会在服务器进程中拥有一个线程，这个连接的查询只会在这个线程中执行，该线程只能轮流在某个CUP核心或者CPU中允许。服务器会负责缓存线程，因为不需要为每个新建的链接创建或者销毁线程。
当客户端连接到MySQL服务器时，服务器需要进行认证，认证基于用户名、原始主机信息和密码。一旦客户端连接成功，服务器会继续验证客户端是否具有执行某个特定操作的权限。
1.1.2 优化与执行
MySQL会解析查询，并创建内部数据结构（解析树），然后对其进行各种优化，包括重写查询、决定表的读取顺序，以及选择合适的索引等。用户可以通过特殊的关键字提示（hint）优化器，影响它的决策过程。也可以请求优化器解释（explain）优化过程的各个因素，使用户可以知道服务器是如何进行优化决策的，并提供一个参考基准，便于用户重构查询和schema（计划），修改相关配置，使尽可能高效运行。
对于select查询，在解析查询之前，服务器会先检查查询缓存（query cache），如果能够在其中找到对应的查询，服务器就不必再执行查询解析、优化和执行的整个过程，而是直接返回查询缓存中的结果集合。
1.2.并发控制
服务器层与层出引擎层的并发控制
1.2.1 读写锁
共享锁和排他锁也叫读锁和写锁
读锁是共享的，或者说叫互不阻塞的，写锁是排他的，写锁会其他的读锁和写锁。
1.2.2 锁粒度
表锁
最基本的锁策略，并且是开销最小的策略
行级锁
行级锁可以最大程序的支持并发处理，同时也带来了最大的锁开销。行级锁只会在存储引擎层实现，而在MySQL服务层没有实现。
1.3 事务
ACID
- 原子性（atomicity）一个事务必须被视为一个不可分割的最小工作单元
- 一致性（consistency）从一个一致性的状态到另外一个一致性的状态
- 隔离性（isolation）事务所做的修改，在其他的事务是不可见的
- 持久性（durability）一旦事务提交，则其所作的修改会永久保存到数据库中
1.3.1 隔离级别
-
未提交读（READ UNCOMMITTED）
事务中的修改，即使没提交，在其他事务中都是可见的，事务可以读取未提交的数据，也被成为脏读。 -
提交读（READ COMMITTED）
没提交前，在其他事务中都是不可见的，也叫不可重复读 -
可重复读（REPETABLE READ）
保证在同一个十五中多次读取同样的记录的结果是一致的，但是可能会导致出现幻读（MySQL的默认事务隔离级别，InnerDB通过多版本并发控制MVCC解决了幻读问题） -
可串行化（SERIALIZEBLE）
最高的隔离级别，强制事务串行执行，简单来说就是会在读取的每一行数据上加锁，所以可能会导致大量的超时和锁争斗的问题。
| 隔离级别 | 脏读可能性 | 不可重复性读可能性 | 幻读可能性 | 加锁读 |
|---|---|---|---|---|
| READ UNCOMMITTED | Yes | Yes | Yes | No |
| READ COMMITTED | No | Yes | Yes | No |
| REPETABLE READ | No | No | Yes | No |
| SERIALIZEBLE | No | No | No | Yes |
1.3.2 死锁
两个或者多个事务在同一个资源上相互占用，并请求锁定对方占用的资源，从而导致恶心循环的现象。
InnerDB目前处理死锁的方法是将最少行级排他锁的事务进行回滚
1.3.3 事务日志
事务日志可以帮助提高事务的效率，使用事务日志，存储引擎在修改表的数据是只需要修改其内存拷贝，再把该修改行为记录到持久在硬盘上的事务日志中，而不是每次都将修改的数本身持久到磁盘。
1.3.4 MySQL中的事务
自动提交（AUTOCOMMIT）
MySQL默认采用自动提交模式，如果不是显示开始一个事务，则每个查询都被当做一个事务执行提交操作。可以通过设置AUTOCOMMIT变量来启用或者禁用自动提交模式。
