前言：
高效读书，一张逻辑图带你读懂、读薄书中重点。
深入学习MySQL系列，解读的目的是为了把书读薄，抽出重点进行梳理、理解、运用。因大量文字很容易让人觉得枯燥无味，为此博主花费一定精力和时间整理输出为逻辑思维图，以便大家学习和参考。
--------------------------------------------------------------------------------------
注：下面文字只是对逻辑思维图的”翻译“，节省时间，只看图即可。
目录
MySQL架构与历史逻辑思维图
MySQL逻辑架构
连接管理与安全性
优化与执行
并发控制
读写锁
锁粒度
锁策略
事务
特性
隔离级别
死锁
事务日志
MySQL中的事务
多版本并发控制
MySQL存储引擎
InnoDB 存储引擎
MyISAM 存储引擎
MySQL 内建的其他存储引擎
第三方存储引擎
选择合适的引擎
转换表的引擎
MySQL时间线
MySQL开发模式
总结
MySQL架构与历史逻辑思维图
MySQL架构与历史
MySQL逻辑架构
三层架构
第一层 连接/线程处理
连接处理、授权认证、安全认证等
第二层 MySQL核心服务
查询解析、分析、优化、缓存以及所有内置函数等
所有跨存储引擎的功能：存储过程、触发器、视图等
第三层 存储引擎
负责MySQL中数据的存储和提取
服务器通过API与存储引擎进行通信，API屏蔽了不同存储引擎之间的差异
存储引擎不会去解析SQL，不同存储引擎之间也不会相互通信
连接管理与安全性
每个客户端连接对应一个线程。服务器会负责缓存，不需要每一个新建的连接创建或者销毁线程
认证基于用户名、原始主机信息和密码
优化与执行
解析查询，创建内部数据结构（解析树）。用户可以请求优化解释（explain）优化过程的各个因素
优化器并不关心使用的是什么存储引擎，但是存储引擎对于优化查询有影响
在解析查询SQL之前，服务器会优先检查查询缓存（Query Cache）
并发控制
多个查询如果在同一时刻修改数据，都会产生并发控制的问题
读写锁
读锁是共享的，或者说是相互不阻塞的
写锁是排他的，也就是说一个写锁会阻塞其他的写锁和读锁
目的：确保在给定的时间里，只有一个用户能执行写入，并防止其他用户读取正在写入的同一资源
锁粒度
目的：提高共享资源并发性的方式，让锁定的对象更有选择性
只锁定需要修改的部分数据，而不是全部资源
只会对修改的数据片进行精确的锁定
锁策略
就是在锁的开销和数据的安全性之间寻求平衡
表锁（talbe lock）
MySQL中最基本的锁策略，并且是开销最小的策略
行级锁（row lock）
可以最大程度地支持并发处理（同时也带来了最大的锁开销）
事务
概念：事务就是一组原子性的SQL查询，或者说是一个独立的工作单元
特性
原子性（atomicity）
原子的概念就是不可分割，你可以把它理解为组成物质的基本单位，也是我们进行数据处理操作的基本单位。
一致性（consistency）
一致性指的就是数据库在进行事务操作后，会由原来的一致状态，变成另一种一致的状态。也就是说当事务提交后，或者当事务发生回滚后，数据库的完整性约束不能被破坏。
隔离性（isolation）
它指的是每个事务都是彼此独立的，不会受到其他事务的执行影响。也就是说一个事务在提交之前，对其他事务都是不可见的。
持久性（durability）
事务提交之后对数据的修改是持久性的，即使在系统出故障的情况下，比如系统崩溃或者存储介质发生故障，数据的修改依然是有效的。因为当事务完成，数据库的日志就会被更新，这时可以通过日志，让系统恢复到最后一次成功的更新状态。
事务的四大特性概括
在这四个特性中，原子性是基础，隔离性是手段，一致性是约束条件，而持久性是我们的目的
隔离级别
READ UNCOMMITTED（未提交读）
事务中的修改，即使没提交，对其他事务也都是可见的
事务可以读取未提交的数据，称为：脏读（Dirty Read）
实际应用中一般很少使用
READ COMMITTED（提交读）
大多数数据库系统的默认级别都是READ COMMITTED（MySQL不是）
一个事务开始时，只能“看见”已经提交的事务所做的修改
这个级别有时候也叫做：不可重复读（nonrepeatableread），因为两次执行同样的查询，可能会得到不一样的结果
REPEATABLE READ（可重复读）
该级别保证了在同一个事务中多次读取同样的记录的结果是一致的
无法解决幻读（Phantom Read）的问题，幻读：指的是当某个事务在读取某个范围内的记录时，另一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行（Phantom Row）
可重复读是MySQL的默认事务隔离级别
SERIALIZABLE（可串行化）
最高的隔离级别
通过强制事务串行执行，避免了幻读的问题
实际应用中很少用，只有当非常确保数据的一致性且可以接受没有并发的情况下，才考虑采用该级别
死锁
概念：指两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象
可能产生情况
当多个事务试图以不同的顺序锁定资源时
当多个事务同时锁定同一个资源时（当两个事务都等待对方释放锁，同时又持有对方需要的锁）
如何解决
死锁检测。检测到死锁的循环依赖，并立即返回一个错误
死锁超时机制。当查询的时间达到锁等待超时的设定后放弃锁请求
大多数情况下，只需要重新执行因死锁回滚的事务即可
事务日志
目的：提高事务效率
使用事务日志，只需修改其内存，再把修改行为记录到硬盘的事务日志中
事务日志持久化以后，内存中被修改的数据在后台再慢慢地刷回到磁盘
MySQL中的事务
MySQL 两种事务型的存储引擎：InnoDB和NDB Cluster
自动提交（AUTOCOMMIT）
MySQL默认采用自动提交（AUTOCOMMIT）模式。意思就是每个查询都被当做一个事务提交操作
在事务中混合使用存储引擎
隐式和显式锁定
多版本并发控制
可以认为MVCC是行级锁的一个变种，但是它在很多情况下避免了加锁操作，因此开销更低
MVCC的实现，是通过保存数据在某个时间点的快照来实现的
InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现的
MVCC 只在REPEATABLE READ（可重复读）和READ COMMITTED（提交读）两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容
MySQL存储引擎
InnoDB 存储引擎
InnoDB是MySQL的默认事务型引擎，也是最重要、使用最广泛的存储引擎
它被设计用来处理大量的短期（short-lived）事务，短期事务大部分情况是正常提交的，很少会被回滚
InnoDB的性能和自动崩溃恢复特性，使得它在非事务型存储的需求中也很流行
概览
InnoDB的数据存储在表空间（tablespace）中，表空间是由InnoDB管理的一个黑盒子，由一系列的数据文件组成
InnoDB 采用MVCC来支持高并发，并且实现了四个标准的隔离级别
InnoDB表是基于聚簇索引建立的
InnoDB内部做了很多优化，包括从磁盘读取数据时采用的可预测性预读，能够自动在内存中创建hash索引加速读操作，以及能够加速插入操作的插入缓冲区等
InnoDB的行为是非常复杂的
InnoDB通过一些机制和工具支持真正的热备份
MyISAM 存储引擎
相关描述
在MySQL 5.1及之前的版本，MyISAM是默认的存储引擎
MyISAM提供了大量的特性，包含全文索引、压缩、空间函数等
MyISAM不支持事务和行级锁，且崩溃后无法安全恢复
存储
MyISAM会将表存储在两个文件中：数据文件和索引文件，分别以.MYD和.MYI为扩展名
MyISAM表如果是变长行，则默认配置只能处理256TB的数据
特性
加锁与并发
MyISAM对整张表加锁，而不是针对行
修复
MySQL可以手动或者自动执行检查和修复操作
索引特性
即使是BLOB和TEXT等长字段，也可以基于前500个字符创建索引；也支持全文索引
延迟更新索引键（Delayed Key Write）
压缩表
压缩表不能进行修改；可以极大地减少磁盘空间占用和磁盘I/O
压缩时表中的记录是独立压缩的，所以读取单行时不需要去解压整个表
性能
设计简单，数据以紧密格式存储，所以某些场景下性能很好
MySQL 内建的其他存储引擎
Archive 引擎
只支持INSERT和SELECT操作，在MySQL5.1前不支持索引
会缓存所有的写并利用zlib对插入的行进行压缩，所以比MyISAM表的磁盘I/O更少
支持行级锁和专用的缓存区，可以实现高并发插入
适用场景
日志或者数据采集
需要更快速的INSERT操作的场景
Blackhole 引擎
没有实现任何存储机制
可以用于复制数据到备库，或者简单地记录到日志
CSV 引擎
可以将普通的CSV文件（逗号分割）作为MySQL表来处理，但是不支持索引
Federated 引擎
是访问其他MySQL服务器的一个代理
Memory 引擎
快速访问数据，且数据不会被修改，重启后丢失也没关系的情景
比MyISAM表要快一个数量级
重启后，结构还会保留，数据会丢失
适用场景
用于查找或者映射表，比如讲邮编和地市名映射的表
用户缓存数据
用户保存数据分析中产生的中间数据
Merge 引擎
是MyISAM引擎的一个变种，由多个MyISAM表合并而来的虚拟表
NDB 集群引擎
作为SQL和NDB原生协议之间的接口
第三方存储引擎
OLTP 类引擎
是基于InnoDB引擎的一个改进版本。改进点主要集中在性能、可测量性和操作灵活性方面
面向列的存储引擎
MySQL默认是面向行的，每一行的数据都是一起存储的，服务器的查询也是以行为单位处理的
面向列的存储方式，在大数据量处理时，可能效率更高，传输更少的数据，每一列的单独存储，压缩效率也会更高
社区存储引擎
Aria、Groonga、OQGraph等
选择合适的引擎
除非需要用到某些InnoDB不具备的特性，并且没有其他办法可以替代，否则都应该优先选择InnoDB引擎
如果应用需要不同的存储引擎，考虑因素如下
事务
备份
崩溃恢复
特有的特性
常见应用场景
日志型应用
实时记录请求日志
插入速度快，MyISAM或者Archive存储引擎比较合适，开销低，且插入速度快
对记录的日志做分析报表
利用MySQL内置的复制方案将数据复制一份到备库
备库上执行耗时间和CPU的查询，主库用于高效的插入操作，互不影响
只读或者大部分情况下只读的表
建议采用InnoDB
订单处理
InnoDB是订单处理类应用的最佳选择
电子公告牌和主题讨论论坛
CD-ROM应用
可以考虑MyIsam表或者MyIsam压缩表
大数据量
数据仓库
转换表的引擎
ALTER TABLE
ALTER TABLE mytable ENGINE=InnoDB；
导出与导入
mysqldump导出文件，修改文件中CREATE TABLE语句的存储引擎选项
创建与查询（CREATE和SELECT）
MySQL时间线
对于怀旧者，自行搜索
MySQL开发模式
遵循GPL开源协议
总结
拥有分层的架构
最初基于ISAM构建（后被MyISAM取代），后续添加了更多的存储引擎和事务支持
存储引擎 API 的架构的缺点。除了InnoDB引擎外的存储引擎，选择可能让事情变得更加复杂
MySQL基于GPL协议开放全部源代码，社区和客户都可以获得坚固而稳定的数据库，变得更加可扩展和有价值
以上内容均为博主原创手码梳理。码字不易，但只要能提高，都是值得的。如果您觉得，这篇文章对您的基础知识学习、巩固、提高有帮助，欢迎点赞、分享、收藏，谢谢。 --天天water
