它的架构可以在多种不同场景发挥好的作用，同时也会带来一点选择上的困难。MySQL并不完美，却足够灵活。
它最与众不同的是它的存储引擎，这种架构的设计将查询处理及其他任务和数据的存储/提取相分离。
1.1 MySQL逻辑架构
1客户端
2 连接/线程处理
查询缓存<——解析器
优化器
3存储引擎（负责数据的存储和提取，服务器通过API和存储引擎通信，除InnoDB外不会解析SQL，InnoDB会解析外键）
第二层：常用功能：查询缓存，解析，优化
第三层：服务器通过API与存储引擎通信，存储引擎负责数据的存储和提取，只会简单响应上层的需求
1.1.1 连接管理和安全性
每个客户端连接都会在服务器端进程中留一个线程
连接成功，会继续验证是否有进行某种查询的权限
1.1.2 优化与执行
MySQL会解析查询，并创建内部数据结构(解析树)，然后进行优化，包括重写查询，决定表的读取顺序，以及选择合适的索引。用户可以通过特殊的关键字提示优化器，影响它的决策过程。
优化器不关心使用了什么存储引擎，但存储引擎对优化是有影响的。
1.2并发控制
只要有多个查询需要在同一时刻修改数据，都会产生并发控制的问题。这里只讨论服务器层与存储引擎层。
1.2.1 读写锁
也叫共享锁和排他锁。某用户修改某数据时，锁定防止其他用户读取同一数据。
1.2.2 锁粒度
尽量只锁需要修改的部分数据，而不是所有的资源。锁定数据量越少，系统的并发度越高。
大多数数据库系统一般是在表上施加“行级锁”,并以各种复杂的方式来实现。
而MySQL提供了多种选择，每种MySQL存储引擎可以实现自己的锁策略和锁粒度。
表锁
表锁是MySQL基本的锁策略，并且是开销最小的策略。
它会锁定整张表，用户对表进行写操作，需要获得写锁，这会阻塞其他用户对表的所有读写操作。没有写锁时，其他用户才能获得读锁。写锁比读锁有更高的优先级，可能会被插入到读锁队列的前面。
行级锁
可以最大程度地支持并发处理，同时也带来最大的锁开销。行级锁只在存储引擎层实现。
1.3 事务
事务就是一组原子性的SQL查询，或者说一个独立的工作单元。要么全部执行，要么全部失败。
一致性：只能由一个完整的状态到另一个完整的状态
我理解为操作都成功了，但其中数值不能有错误。还是中间状态外部不能看到。
原子性并不能完全保证一致性
ACID：原子性，一致性，隔离性，持久性
1.3.1 隔离级别
READ UNCOMMITED 未提交读（脏读）：其实没有提交，对其他事务也是可见的。
READ COMMITED 提交读（不可重复读）：正常数据库系统的默认隔离级别
可重复读：解决脏读问题，保证同一事务中多次读取记录一样。不能解决幻读：读取一定范围时，另一个事务有插入了新的记录（InnoDB通过多版本并发控制MVVC解决了幻读）
可串行化：最高的隔离级别。会在读取的每一行都加上锁。
1.3.2 死锁
InnoDB目前解决死锁：将持有最少行级锁的事务回滚
锁的行为和顺序和存储引擎是相关的。死锁产生原因：数据冲突、存储引擎的实现。
解决：部分或完全回滚其中一个事务
1.3.3 事务日志
使用事务日志，修改表的数据只需修改内存拷贝，再把修改行为记录到持久在磁盘的日志中。修改数据需要写两次磁盘。
1.3.4
锁只有COMMIT或ROLLBACK时才会释放
除了事务中禁用AUTOCOMMIT，可以用LOCK TABLES外，其他不要用
1.4 多版本并发控制
大多数存储引擎使用的不是简单的行级锁，基于并发性能的考虑，还使用了MVCC。可以认为它是行级锁的变种，很多情况下避免了加锁。
它是通过保存数据在某个时间点的快照来实现的。实现了非阻塞的读操作，锁定必要的行。
SELECT：InnoDB只查找版本早于当前事务版本的数据行
行的删除版本要么未定义，要么大于当前事务版本号
INSERT：保存当前系统版本号作为行版本号
DELETE：保存当前系统版本号作为删除标识
不足之处是每行都需要额外的存储空间
MVCC只在重复读和提交读两个隔离级别工作。
1.5 MySQL的存储引擎
创建表时，Mysql会在数据库子目录下创建和表同名的.frm文件保存表的定义。
InnoDB是MySql 5.5后的默认事务性引擎，用来处理大量的短期事务，它的性能和崩溃自动恢复特性，使之流行。
InnoDB通过间隙锁防止幻读。
InnoDB表通过聚簇索引实现的。聚簇索引对主键查询有很强的性能
能够从磁盘读取数据时采用可预测性读。
支持在线热备份。
1.5.2 MyIsam引擎
MySQL5.1前，它是默认存储引擎。有大量特性，但不支持事务和行级锁，崩溃后无法安全修复
下面的很多小节不太需要记住，就不写啦~