1.1 MySQL架构与历史
存储引擎不会去解析SQL，不同存储引擎也不会互相通信，InnoDB是个例外，它会解析外键定义
1.1.1 连接管理和安全性
5.5 开始支持线程池插件
1.1.2 优化与执行
对于SELECT语句，在解析查询之前，服务器会先检查查询缓存，如果能够在其中找到对应的查询，服务器就不必再执行查询解析、优化和执行的整个过程，而是直接返回查询缓存中的结果集。
1.2 并发控制
层面：服务器层与存储引擎层
1.2.1 读写锁
共享锁 => 读锁 排他锁 => 写锁
1.2.2 锁粒度
表锁 行级锁（存储引擎）
1.3 事务
一组原子性的SQL查询，或者说一个独立的工作单元
ACID：
原子性(Atomicity) 一个事务必须被视为一个不可分隔 的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚
一致性(Consistency) 数据库总是从一个一致性的状态转换到另一个一致性的状态
隔离性(Isolation) 一个事务所做的修改在最终提交以前，对其他事务是可不见的
持久性(durability) 一旦事务提交，则其所作的修改就会永久保存到数据库中
1.3.1 隔离级别
未提交读 提交读 可重复读 可串行化
较低级别的隔离通常可以执行更高的并发，系统的开销也更低
隔离级别 脏读可能性 不可重复读可能性 幻读可能性 加锁读
READ UNCOMMITTED Yes Yes Yes No
READ COMMITTED No Yes Yes No
REPEATABLE READ No No Yes No
SERIALIZABLE No No No Yes
脏读：事务可以读取未提交的数据
幻读：当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行
1.3.2 死锁
死锁是指两个或多个事务在同一资源上互相占用，并请求锁定对方占用的资源，从而导致恶行循环的现象
InnoDB目前处理死锁的方式是，将持有最少行级排他锁的事务进行回滚。
死锁的产生有双重原因：有些事因为真正的数据冲突，这种情况通常很难避免，但有些则完全是由于存储引擎的实现方式导致的。
1.3.3 事务日志
事务日志可以帮助提高事务的效率。使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把改修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据本书持久到磁盘。事务日志采用的时追加的方式，因此写日志的操作时磁盘上一小块区域内的顺序I/O，而不想随机I/O需要在磁盘的多个地方移动磁头，所以采用事务日志的方式相对来说要快得多。事务日志持久以后，内存中被修改的数据在后台可以慢慢地刷回磁盘。
1.3.4 MySQL 中的事务
自动提交（AUTOCOMMIT）：
当AUTOCOMMIT=0时，所有的查询都是在一个事务中，直到显示地执行COMMIT提交或者ROLLBACK回滚，该事务结束，同时又开始了另一个新事务。
在事务中混合使用存储引擎
MySQL服务器层不管理事务，事务是由下层地存储引擎实现地。==>在同一个事务中，使用多重引擎是不可靠的。
隐式和显式锁定
在事务执行过程中，随时都可以锁定，锁只有在执行COMMIT或者ROLLBACK的时候才会释放，并且所有的锁是在同一时刻释放。前面描述的锁定都是隐式锁定，InnoDB回根据隔离级别在需要的时候自动加锁。
InnoDB也支持通过特定的语句进行显式锁定，这些语句不属于SQL规范
SELECT ... LOCK IN SHARE MODE
SELECT ... FOR UPDATE
1.4 多版本并发控制 MVVC
SELECT
InnoDB 只查找版本早于当前事务版本的数据行（也就是，行的系统版本号小于或者等于事务的系统版本号）确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。
行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除。
INSERT
InnoDB 为新插入的每一行保存当前系统版本号作为行版本号
DELETE
InnoDB为删除的每一行保存当前版本号作为行删除标识
UPDATE
InnoDB 为插入一行新纪录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。
MVVC只在REPEATABLE READ 和 READ COMMITTED 两个隔离级别下工作。
READ UNCOMMITTED总是读取足心的数据行，而不是符合当前事务版本的数
据行，而SERIALIZABLE 则会对所有读取的行都枷锁。
1.5 MySQL存储引擎
1.5.1 InnoDB 存储引擎
被设计用来处理大量的短期事务
InnoDB的数据存储在表空间中，表空间是InnoDB管理的一个黑盒子，由一系列的数据文件组成
InnoDB采用MVCC来支持高并发，并且实现了四个标准的隔离级别。其默认级别是REPEATABLE READ ，并且通过间隙锁策略防止幻读的出现。
支持热备份 其他引擎不支持
1.5.2 MyISAM 存储引擎（数据文件.MYD 索引文件.MYI）
支持全文索引、压缩、空间函数等，但不支持事务和行级锁，崩溃后无法恢复
特性：
加锁与并发： 对整张表加锁。
修复
支持全文索引
延迟更新索引键 写入内存的键缓存区
如果表在创建并导入数据以后，不会再进行修改操作，那么这样的表或许适合采用MyISAM压缩表
1.5.3 内建的其他存储引擎
Archive：只支持select 和 insert，每次SELECT查询都需要全表扫描，支持行级锁和专用的缓冲区，可以实现高并发的插入，适合日志和数据采集类应用，或者一些需要更快速insert操作的场合。
Blackhole：没有实现任何的存储机制，会丢弃所有插入的数据，不做任何保存。可以用于复制数据到备库，或者只是简单地记录到日志。
CSV：可以将普通地csv文件（逗号分割值的文件）作为MySQL的表来处理，但不支持索引。可以作为一种数据交换的机制
Federated：访问其他MySQL服务器的一个代理，最初设计初衷是为了和SQL Server、Oracle竞争。默认禁用
Memory：需要快速地访问数据，并且这些数据不会被修改，重启后丢失也没关系，那么使用Memory表是非常有用的。
场景：
用于查找或者映射表，例如将邮编和州名映射的表
用于缓存周期性聚合数据的结果
用于保存数据分析中产生的中间数据
缺点：
表级锁，并发写入性能低
不支持BLOB 和TEXT类型的列，并且每行的长度是固定的。（即使指定了VARCHAR，实际存储时也会转换为CHAR，导致内存浪费）
Merge：MyISAM引擎的一个变种。 是由多个MyISAM表合并而来的虚拟表。 用于日志或者数据仓库类应用
NDB集群：
1.5.5 引擎选型
事务 InnoDB XtraDB
不需要事务 主要是SELECT和INSERT操作 MYISAM
备份 InnoDB（在线热备份）
崩溃恢复 InnoDB
特有的特性
日志型应用：MyISAM Archive（开销低，插入速度快）
CD-ROM应用 MyISAM
