：MySQL架构与历史
Posted 紫荆之后-
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了：MySQL架构与历史相关的知识，希望对你有一定的参考价值。
本章概述
作为高性能mysql一书的开篇章节，本章概要地描述了MySQL的服务器架构、各种存储引擎之间的主要区别，以及这些区别的重要性，同时介绍了MySQL的历史背景和基准测试（第二章会详细讲述）
1.1 Mysql逻辑架构
分为client客户端，server层和存储结构三部分
第一步，首先用户向server发送连接请求，server连接器提供连接服务，做一些权限认证，比如用户名和密码
第二步，分析器把sql语句进行切分，通过词法分析和语法分析最终转成抽象语法树（Abstract Syntax Tree，AST）
第三步，sql语句有N种执行方式，优化器对其进行优化，不同的执行方式对SQL语句的执行效率影响很大
– RBO:基于规则的优化
– CBO:基于成本的优化（用的多）
第四步，执行器，跟存储引擎挂钩，操作引擎，返回结果
| MySQL服务器逻辑架构图 |
|---|
 |
 |
最上层是通用服务，非MySQL独有
第二层包含了MySQL大多数的核心服务功能，包括查询解析、分析、优化、缓存以及日期、时间、数学和加密函数等内置函数，跨存储引擎的功能如存储过程、触发器、视图等也在这一层实现
第三层主要是存储引擎，存储引擎的API包含几十个而底层函数，但存储引擎不会解析事务（InnoDB是个例外，它会解析外键定义，因为MySQL服务器本身没有实现该功能），不同引擎之间不会通信，只会响应上层服务器的请求
1.1.1 连接管理与安全性
一个客户端连接对应一个服务器中的一个线程，该连接的查询只在线程中执行
付费版本mysql-Percona支持线程池插件，可以使用池中少量的线程来服务大量的连接，在前置环节，比如spring的声明式事务就可以通过ThreadLocal实现线程的复用，这两点本质上解决的都是同一个问题
1.1.2 优化与执行
优化器不关心表使用的是什么存储引擎，但存储引擎对于优化查询是有影响的
对于select语句，服务器在解析查询之前会先检查查询缓存
注意：查询缓存MySQL8中被弃用
1.2 并发控制
本章讨论MySQL两个层面的并发控制：服务器层与存储引擎层
1.2.1 读写锁
简单说下概念：读锁也叫共享锁，多个客户在同一时刻可以同时读取同一个资源；写锁也叫排他锁，一个写锁会阻塞其他的写锁和读锁，确保在给定的时间里，只有一个用户能执行写入，并防止其他用户读取正在写入的同一资源
1.2.2 锁粒度
表锁
表锁是MySQL中开销最小的策略，它会锁定整张表，这可以很好地避免死锁问题。进行写操作前需要先获得写锁，这会阻塞其他的读写操作，只有没有写锁时，其他读取的用户才能获得读锁
在特定场景中表锁也有良好的性能。例如，READ LOCAL表锁支持某些类型的并发写操作。另外，写锁的优先级高于读锁，一个写锁请求可能会被插入到读锁队列的前面，反之则不行
服务器会为诸如ALTER TABLE之类的语句使用表锁，而忽略存储引擎的锁机制
行级锁
行级锁可以最大程度地支持并发处理，同时也带来了最大的锁开销。行级锁只在存储引擎中实现，服务器层完全不了解存储引擎中的锁实现
意向锁
事务在添加共享锁（行级）之前，需要先添加意向共享锁（表级）。在添加排他锁（行级）之前，需要先获取意向排他锁（表级），在 InnoDB 中，我们对某条记录进行锁定时，为了提高并发度，通常都只是锁定这一行记录，而不是锁定整个表。而当我们需要为整个表加写锁的时候，我们就需要遍历整个表的记录，如果每条记录都没有被加锁，才可以给整个表加写锁。而这个遍历过程就很费时间，这时候就有了意向锁的诞生
意向锁其实就是标记这个表有没有被锁，如果有某条记录被锁住了，那么就必须获取该表的意向锁。所以当我们需要判断这个表的记录有没有被加锁时，直接判断意向锁就可以了，减少了遍历的时间，提高了效率，是典型的用空间换时间的做法
1.3 事务
事务就是一组原子性的SQL查询，或者说一个独立的工作单元，事务内的语句，要么全部执行成功，要么全部执行失败
ACID略
1.3.1 隔离级别
READ UNCOMMITTED（未提交读）
未提交读，事务中的修改，即使没有提交，对其他事务也都是可见的，事务可以读取未提交的数据，这也被称为脏读。该级别一般很少使用
READ COMMITTED（提交读）
一个事物从开始直到提交之前，所做的任务修改对其他事务都是不可见的，也叫不可重复读，因为两次执行同样的查询，可能会得到不一样的结果（比如b事务在a事务提交前读了一次数据，在a事务提交之后又读了一次事务，两次结果不一致）
REPEATABLE READ（可重复读）
解决脏读问题，该级别保证了在同一个事务中多次读取同样记录的结果是一致的，但无法解决幻读，即当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行。InnoDB和XtraDB存储引擎通过多版本并发控制解决了幻读的问题
SERIALIZABLE（可串行化）
这是最高的隔离级别，它通过强制事务串行执行来避免幻读
缺点：在读取的每一行数据上都加锁，可鞥导致大量的超时和锁争用的问题
| sql隔离级别 |
|---|
 |
1.3.2 死锁
死锁是指两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源从而导致恶性循环的现象
| 设想下面两个事务同时处理StockPrice表 |
|---|
 |
InnoDB目前处理死锁的方法是：将持有最少行级排他锁的事务进行回滚
死锁发生以后，只有部分或者完全回滚其中一个事务才能打破死锁。应用程序的处理大多数情况下只需重新执行因死锁回滚的事务即可
1.3.3 事务日志
事务日志可以使存储引擎在修改数据时只修改其内存拷贝，再把该修改行为记录到硬盘中的事务日志中，而不用每次都持久化到磁盘。事务日志是追加方式，顺序io。事务日志持久以后，内存中被修改的数据在后台可以慢慢地刷回到磁盘
1.3.4 Mysql中的事务
自动提交（AUTOCOMMIT）
MySQL默认采用自动提交模式，也就是说，如果不是显式地开始一个事务，则每个查询都被当作一个事务执行提交操作。可以通过设置AUTOCOMMIT变量值启用或禁用，1/ON启用，0/OFF禁用
还有一些命令在执行之前会强制执行COMMIT提交当前的活动事务，比如ALTER TABLE，LOCK TABLES
在事务中混合使用存储引擎
是不可靠的，服务器层不管理事务，非事务型表上的变更无法撤销回滚
隐式和显式锁定
InnoDB采用两阶段锁定协议，即加锁阶段和解锁阶段。事务执行过程中随时都可以锁定，锁只有在执行COMMIT或者ROLLBACK的时候才会释放，并且所有锁是在同一时刻被释放。这些都是隐式锁定，InnDB会根据隔离级别在需要的时候自动加锁。另外InnoDB也支持通过特定的语句进行显式锁定，但应谨慎使用：
- SELECT . . . LOCK IN SHARE MODE
- SELECT . . . FOR UPDATE
服务器层也支持LOCK TABLES和UNLOCK TABLES，但并不能代替事务
1.4 多版本并发控制
MVCC是行级锁的一个变种，它在很多情况下避免了加锁操作，因此开销更低。实现了非阻塞的读操作，写操作也只锁定必要的行
MVCC的实现，是通过保存数据在某个时间点的快照来实现的。也就是说，不管需要执行多长时间，每个事务看到的数据都是一致的（不会被其他事务影响），根据事务开始的时间不同，每个事物对同一张表，同一时刻看到的数据可能是不一样的
InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现的。一个保存了行的创建时间，一个保存行的过期时间（或删除时间）。存储的是系统版本号。每开始一个事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较
MVCC的两个实现核心是undo log和一致性视图，通过undo log来保存多版本的数据，通过一致性视图来保存当前活跃的事务列表，将两者结合和制定一定的规则来判断当前可读数据
https://zhuanlan.zhihu.com/p/231947511
在REPEATABLE READ隔离级别下，MVCC具体操作如下：
SELECT
InnoDB会根据以下两个条件检查每行记录：
a. InnoDB只查找版本早于当前事务版本的数据行（也就是，行的系统版本号小于或等于事务的系统版本号），这样可以确保事务 读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的
b. 行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除
只有符合上述两个条件的记录，才能返回作为查询结果
INSERT
InnoDB为新插入的每一行保存当前系统版本号作为行版本号
DELETE
InnoDB为删除的每一行保存当前系统版本号作为行删除标识
UPDATE
InnoDB为插入一行新纪录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识
MVCC只在REPEATABLE READ和READ COMMITTED两个隔离级别下工作
为了实现事务的原子性，InnoDB存储引擎在实际进行增、删、改一条记录时，都需要先把对应的undo日志记下来。一般每对一条记录做一次改动，就对应着一条undo日志，但在某些更新记录的操作中，也可能会对应着2条undo日志。一个事务在执行过程中可能新增、删除、更新若干条记录，也就是说需要记录很多条对应的undo日志，这些undo日志会被从0开始编号，也就是说根据生成的顺序分别被称为第0号undo日志、第1号undo日志、…、第n号undo日志等，这个编号也被称之为undo no。
聚簇索引的记录除了会保存完整的用户数据以外，而且还会自动添加名为trx_id、roll_pointer的隐藏列，如果用户没有在表中定义主键以及UNIQUE键，还会自动添加一个名为row_id的隐藏列。
其中的trx_id列就是某个对这个聚簇索引记录做改动的语句所在的事务对应的事务id而已。
trx_id：每次一个事务对某条聚簇索引记录进行改动时，都会把该事务的事务id赋值给trx_id隐藏列。
roll_pointer：每次对某条聚簇索引记录进行改动时，都会把旧的版本写入到undo日志中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息。
每次对记录进行改动，都会记录一条undo日志，每条undo日志也都有一个roll_pointer属性（INSERT操作对应的undo日志没有该属性，因为该记录并没有更早的版本），可以将这些undo日志都连起来，串成一个链表，所以现在的情况就像下图一样：
对该记录每次更新后，都会将旧值放到一条undo日志中，就算是该记录的一个旧版本，随着更新次数的增多，所有的版本都会被roll_pointer属性连接成一个链表，我们把这个链表称之为版本链，版本链的头节点就是当前记录最新的值。另外，每个版本中还包含生成该版本时对应的事务id。于是可以利用这个记录的版本链来控制并发事务访问相同记录的行为，那么这种机制就被称之为多版本并发控制(Mulit-Version Concurrency Control MVCC)。
1.5 MySQL中的存储引擎
1.5.1 InnoDB存储引擎
InnoDB采用MVCC开支持高并发，默认存储引擎是REPEATABLE READ，并且通过间隙锁（next-key locking）策略防止幻读的出现。间隙锁使得InnoDB不仅仅锁定查询涉及的行，还会对索引中的间隙进行锁定，以防止幻影行的插入
InnoDB表是基于聚簇索引建立的，聚簇索引对主键查询有很高的性能。不过它的二级索引中必须包含主键列，如果主键列很大的话，其他的所有索引都会很大。因此，若表上的索引较多的话，主键应当尽可能地小
InnoDB内部做了很多优化，包括从磁盘读取文件时采用的可预测性预读，能够自动在内存中创建hash索引以加速读操作的自适应哈希索引，以及能够加速插入操作的插入缓冲区等
1.5.2 MyISAM存储引擎
在5.5之前，也就是5.1及之前的版本，MyISAM是默认的存储引擎，不支持事务和行级锁崩溃后无法安全恢复
MyISAM将表存储在两个文件中：数据文件.MYD和索引文件.MYI
MyISAM可以存储的行记录数，一般受限于可用的磁盘空间，或者操作系统中单个文件的最大尺寸
可以通过修改表的MAX_ROWS和AVG_ROW_LENGTH选项的值来改变MyISAM表指针的长度，两者相乘就是表可能达到的最大大小。但是修改会导致重建整个表和表的所有索引，耗时很长
MyISAM对整张表加锁，读操作时也可以插入，这被称为并发插入
可以通过CHECK TABLE mytable检查表的错误，通过REPAIR TABLE mytable进行修复。另外，如果MySQL服务器已经关闭，可以通过myisamchk命令行工具进行检查和修复操作
MyISAM可以对长字段基于其前500个字符创建索引，也支持全文索引
创建MyISAM表的时候，如果指定了DELAY_KEY_WRITE（延迟更新索引键）选项，在每次修改执行完成时，不会立刻将修改的索引数据写入磁盘，而是写到内存中的键缓冲区，只有在清理键缓冲区或关闭表的时候才会将对应的索引块写入到磁盘。这种方式可以极大地提升写入性能，但在数据库或主机崩溃时会造成索引损坏，需要执行修复操作。延迟更新索引键可以在全局设置也可以为单个表设置
使用myisampack对MyISAM表进行压缩，压缩表不能修改除非先解压。压缩表减少了磁盘的空间占用，因此也减少了磁盘I/O，从而提升查询性能。压缩表也支持索引，但索引也是只读的。表中的数据是独立压缩的，读取单行不需要解压整个表
MyISAM最调性的性能问题就是表锁的问题
1.5.3 Mysql内建的其他存储引擎
Archive、Blackhole、CSV、Federated、Merge、NDB集群引擎等引擎暂时略过
Memory引擎
适用于需要快速访问数据，且这些数据不会被修改，丢失无碍。比MyISAM快一个数量级，因为所有表都在内存中不需要进行磁盘I/O，底层是hash索引而非B+树。Memory表的结构重启之后还会保留但数据会丢失
应用场景：
- 用于查找或者映射表，例如将邮编和州名映射的表
- 用于缓存周期性聚合数据的结果
- 用于保存数据分析中产生的中间数据
Memory也是表级锁，每行的长度是固定的，就算指定了varchar也会转成char
如果MySQL在执行查询的过程中需要使用临时表保存中间结果，内部使用的临时表就是Memory表，如果中间结果太大超出Memory限制，或者含有BLOB或TEXT字段，则会转成MyISAM表
1.5.4 第三方存储引擎（暂时略过）
1.5.5 选择合适的引擎
需要事务支持用InnoDB，如果不需要十五且主要是SELECT和INSERT操作可以使用MyISAM（如日志型应用）
需要在线热备份用InnoDB，如果可以定期关闭服务器来执行备份可以忽略这条
崩溃恢复用InnoDB
1.5.6 转换表的引擎
ALTER TABLE
ALTER TABLE mytable ENGINE = InnoDB；
适用任何引擎，但执行时间长，复制期间原表会加读锁
导出与导入
使用mysqldump工具将数据导出到文件，然后修改CREATE TABLE语句中的存储引擎选项并同时修改表名。同时要注意mysqldump默认会自动在CREATE TABLE语句前加上DROP TABLE语句，要注意这一点防止数据丢失
创建与查询（推荐）
MySQL之架构与历史
MySQL架构与历史
和其他数据库系统相比，MySQL有点与众不同，它的架构可以在多种不同的场景中应用并发挥好的作用，但同时也会带来一点选择上的困难。MySQL并不完美，却足够灵活，它的灵活性体现在很多方面。例如，你可以通过配置使它在不同的硬件上都运行得很好，也可以支持多种不同的数据类型。但MySQL最重要的是它的存储引擎架构，这种架构的设计将查询处理、及其他系统任务和数据的存储/提取相分离。这种处理和存储分离的设计可以在使用时根据性能、特性以及其他需求来选择数据的存储方式。
MySQL逻辑架构
图1-1展示了MySQL的逻辑架构图
图1-1 MySQL服务器逻辑架构图
最上层的服务并不是 MySQL 所独有的，大多数基于网络的客户端/服务器的工具或者服务都有类似的架构。比如连接处理、授权认证、安全等等。
第二层构架是 MySQL 比较有意思的部分。大多数 MySQL 的核心服务功能都在这一层，包括查询结息、分析、优化、缓存以及所有的内置函数（例如：日期、时间、数学和加密函数），所有跨存储引擎的功能都在这一层实现：存储过程、触发器、视图等。
第三层包含了存储引擎。存储引擎负责 MySQL 中数据的存储和提取。和 GNU/Linux 下的各种文件系统一样，每个存储引擎都有它的优势和劣势。服务器通过 API 与存储引擎进行通信。这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层的查询过程透明。存储引擎 API 包含了几十个底层函数，用于执行诸如 “开始一个事务” 或者 “根据主键提取一行记录” 等操作。但存储引擎不会去解析 SQL (InnoDB 是一个例外，它会解析外键定义，因为 MySQL 服务器本身没有实现该功能)，不同存储引擎之间也不会互相通信，而只是简单地响应上层服务器的请求。
连接管理与安全性
每个客户端连接都会在服务器进程中拥有一个线程，这个连接的查询只会在这个单独的线程中执行，该线程只能轮流在某个CPU核心或者CPU中运行。服务器会负责缓存线程，因此不需要为每一个新建的连接创建或者销毁线程。（注：MySQL5.5或者更新的版本提供的一个API，支持线程池插件，可以使用池中少量的线程来服务大量的连接）。
当客户端（应用）连接到MySQL服务器时，服务器需要对其进行认证。认证基于用户名，原始主机信息和密码。如果使用了安全套接字（SSL）的方式连接，还可以使用X.509证书认证。一旦客户端连接成功，服务器会继续验证客户端是否具有某个特定查询的权限（例如，是否允许客户端对world数据库的Country表执行SELECT语句）。
优化与执行
MySQL会解析查询，并创建内部数据结构（解析树），然后对其进行各种优化，包括重写查询，决定表的读取顺序，以及选择合适的索引等。用户可以通过特殊的关键字提示（hint）优化器，影响它的决策过程。也可以请求优化器解释（explain）优化过程的各个因素，使用户可以知道服务器是如何进行优化决策的，并提供一个参考基准，便于用户重构查询和schema，修改相关配置，是应用尽可能高效运行。
优化器并不关心使用的是什么存储引擎，但存储引擎对于优化查询是有影响的。优化器会请求存储引擎提供容量或某个具体操作的开销信息，以及表数据的统计信息等。例如，某些存储引擎的某种索引，可能对一些特定的查询有优化。
对于SELECT语句，在解析查询之前，服务器会先检查查询缓存（Query Cache），如果能够在其中找到对应的查询，服务器就不必再执行查询解析、优化和执行的整个过程，而是直接返回查询缓存中的结果集。
并发控制
无论何时，只有有多个查询需要在同一时刻修改数据，都会产生并发控制的问题。这里讨论MySQL在两个层面的并发控制：服务器层与存储引擎层。并发控制是一个内容庞大的话题，有大量的理论文献对其进行详细的论述。这里只是简要地讨论MySQL如何控制并发读写。
以Unix系统的email box为例子，典型的mbox文件格式是非常简单的。一个mbox邮箱中的所有邮件都串行在一起，彼此首尾相连。这种格式对于读取和肥西邮件信息非常友好，同时投递邮件也很容易，只要在文件末尾附加新的邮件内容即可。
但是如果两个进程在同一时刻对同一个邮箱投递邮件，会发生什么情况？显然，邮箱的数据会被破坏，两封邮件的内容会交叉地附加在邮箱文件的末尾。设计良好的邮箱投递系统会通过锁（lock）来防止数据损坏。如果客户试图投递邮件，而邮箱已经被其他客户锁住，那么就必须等待，直到锁释放才能进行投递。
这种锁的方案在实际应用环境中虽然工作良好，但是并不支持并发处理。因为在任意一个时刻，只有一个进程可以修改邮箱的数据，这在大容量的邮箱系统中是个问题。
读写锁
从邮箱中读取数据没有这样的麻烦，即使同一时刻多个用户并发读取也不会有什么问题。因为读取不会修改数据，所以不会出错。但是如果某个客户正在读取邮箱，同时另一个用户试图删除编号为25的邮件，会产生什么结果？结论是不确定的，读的客户可能会报错退出，也可能读取不到一致的邮箱数据。所以，为了安全起见，即使是读取邮箱也需要特别注意。
如果把上述的邮箱当成数据库中的一张表，把邮件当成表中的一行记录，就很容易看出，同样的问题依然存在。从很多方面来说，邮箱就是一张简单的数据库表。修改数据库表中的记录，和删除或者修改邮箱中的邮件信息，十分类似。
解决这类经典的问题的方法就是并发控制（读锁和写锁）。其实非常简单，在处理并发读或者写的时候，可以通过实现一个由两种类型的锁组成锁系统来解决问题。这两种类型的锁通常被称为共享锁（shared lock）和排他锁（exclusive lock），也叫读锁（read lock）和写锁（write lock）。
这里先不讨论如何具体实现，描述一下锁的概念如下：读锁是共享的，或者说是相互不阻塞的。多个客户在同一时刻可以同时读取同一资源，而互不干扰。写锁则是排他的，也就是说一个写锁会阻塞其他的写锁和读锁，这是出于安全策略的考虑，只有这样，才能确保给定的时间里，只有一个用户能执行写入，并防止其他用户读取正在写入的同一资源。
在实际的数据库系统中，每时每刻都在发生锁定，当某个用户在修改某一部分数据的时候，MySQL会通过锁定防止其他用户读取同一数据。大多数时候，MySQL锁的内部管理都是透明的。
锁粒度
一种提供共享资源并发性的方式就是让锁定对象更有选择性。尽量只锁定需要修改的部分数据，而不是所有的资源。更理想的方式是，只对会修改的数据片（具体到锁定所修改的字段）进行精确的锁定。任何时候，在给定的资源上，锁定的数据量越少，则系统的并发程度越高，只要互相之间不发生冲突即可。
问题是加锁也需要消耗资源。锁的各种操作，包括获得锁，检查锁是否已经被解除，释放锁等，都会增加系统的开销。如果系统花费大量的时间来管理锁，而不是存取数据，那么系统的性能可能因此受到影响。
所谓的锁策略，就是在锁的开销和数据的安全性之间寻求平衡，这种平衡当然有会影响到性能，大多数商业数据库系统没有提供更多的选择，一般都是在表上施加行级锁（row-level lock），并以各种复杂的方式来实现，以便在锁比较多的情况下尽可能地提供更好的性能。
而MySQL则提供多种选择，每种MySQL存储引擎都可以实现自己的锁策略和锁粒度。在存储引擎的设计中，锁管理是个非常重要的决定。将锁粒度固定在某个级别，可以为某些特定的应用场景提供更好的性能。但是同事却会失去对另外一些应用场景的良好支持。好在Mysql支持多个存储引擎的架构，所以不需要单一的通用解决方案。下面介绍两种最重要的锁策略。
表锁（table lock）
表锁是MySQL中最基本的锁策略，并且是开销最小的策略。表锁非常类似于前文描述的邮箱加锁机制：它会锁定整张表。一个用户在对表进行写操作（插入，删除，更新等等）前，需要先获得写锁，这个会阻塞其他用户对该表的所有读写操作。只有没有写锁的时候，其他读取的用户才能获得读锁，读锁之间是不互相阻塞的。
在特定的场景中，表锁也可能有良好的性能。例如，read local表锁支持某些类型的并发写操作。另外，写锁也比读锁有更高的优先级，因此一个写锁请求可能会被插入到读锁队列的前面（写锁可以插入到锁队列中读锁的前面，反之读锁则不能插入写锁的前面）。
尽管存储引擎可以管理自己的锁，MySQL本身还是会使用各种有效的表锁来实现不同的目的。例如服务器会诸如ALTER TABLE之类的语句使用表锁，而忽略存储引擎的锁机制。
行级锁（row lock）
行级锁可以最大程度地支持并发处理（同时也带来了最大的锁开销）。众多周知，在InnoDB和XtraDB，以及其他一些存储引擎中实现了行级锁。行级锁只在存储引擎层实现，而MySQL服务器层没有实现。服务器层完全不了解存储引擎中的锁实现。
事物
事物是一组原子性的SQL查询，或者说是一个独立的工作单元。如果数据库引擎能够成功地对数据库应用该组查询的全部语句，那么就执行该组查询。如果其中任何一条语句因为崩溃或其他原因无法执行，那么所有语句都不会执行。也就是说，事务内的语句，要么全部执行成功，要么全部执行失败。
事务的四大特性（ACID）：
- 原子性（atomicity）：一个事务必须视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚，对于一个事务来说，不可能只执行其中的一部分操作，这就是事务的原子性。
- 一致性（consistency）：数据库总数从一个一致性的状态转换到另一个一致性的状态。
- 隔离性（isolation）：一个事务所做的修改在最终提交以前，对其他事务是不可见的。
- 持久性（durability）：一旦事务提交，则其所做的修改就会永久保存到数据库中。此时即使系统崩溃，修改的数据也不会丢失。
就像锁粒度的升级会增加系统开销一样，这种事务处理过程中额外的安全性，也会需要数据库系统做更多的额外工作。一个实现了ACID的数据库，相比没有实现ACID的数据库，通常会需要更强的CPU处理能力、更大的内存和更多的磁盘空间。正如我们之前所说，这也正是MySQL的存储引擎架构可以发挥优势的地方。用户可以根据业务是否需要事务处理，来选择合适的存储引擎。对于一些不需要事务的查询类应用，选择一个非事务型的存储引擎，可以获得更高的性能。即使存储引擎不支持事务，也可以通过LOCK TABLES语句为应用提供一定程度的保护，这些选择用户都可以自主决定。对于一些不需要事物的查询类应用，选择一个非事务型的存储引擎，可以获得更高的性能。即使存储引擎不支持事物，也可以通过LOCK TABLES语句为应用提供一定程度的保护，这些选择用户都可以自己决定。
隔离级别
在SQL标准中定义了四种隔离级别，每一种级别都规定了一个事务中所做的修改，哪些是在事务内和事务间可见的，哪些是不可见的。较低级别的隔离通常可以执行更高的并发，系统的开销也更低。
READ UNCOMMITED（读未提交）
在RERAD UNCOMMITED级别，事务中的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也成为脏读（Dirty Read）。这个级别会导致很多问题，从性能上说READ UNCOMMITED 不会比其他的级别好太多，但缺乏其他级别的好多好处，除非有非常必要的理由，在实际的应用中一般很少使用。
创建一个数据库，执行下面的数据库语句。
create table if not exists `account`(
`id` int(11) primary key auto_increment,
`name` varchar(32),
`balance` int(11) not null
)engine=innodb default charset=utf8;
insert into `account`(`name`,`balance`) values("Amy", 1000);
insert into `account`(`name`,`balance`) values("Tom", 500);
insert into `account`(`name`,`balance`) values("John", 350);
打开客户端A，并设置当前事物模式为RERAD UNCOMMITED（读未提交）级别，查询表account的数据
# 客户端A mysql> set session transaction isolation level read uncommitted; Query OK, 0 rows affected (0.00 sec) mysql> start transaction; Query OK, 0 rows affected (0.00 sec) mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 1000 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec)
在客户端A的事物提交前，打开另一个客户端B，更新表account，将id为1的用户余额减去500，再重新查询account表的数据
# 客户端B mysql> set session transaction isolation level read uncommitted; Query OK, 0 rows affected (0.00 sec) mysql> start transaction; Query OK, 0 rows affected (0.00 sec) mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 1000 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec) # 将id为1的用户余额减去500 mysql> update account set balance = balance - 500 where id = 1; Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 500 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec)
然后，我们再回到客户端A，查询account表的数据，可以看到，尽管B的事物尚未提交，但客户端A已经能看到客户端B修改的数据了
# 客户端A mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 500 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec)
这时候，如果客户端B回滚，让account恢复到修改前的状态
# 客户端B mysql> rollback; Query OK, 0 rows affected (0.06 sec) mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 1000 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec)
客户端A依旧以为id为1的用户的余额是500，再次执行更新（余额减去500）语句，会发现先余额没有变动
# 客户端A mysql> update account set balance = balance - 500 where id = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 500 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec)
上面的例子就是未提交读的示例，两个并行的事物可以看到对方修改的数据。明明读到id为1的用户余额为500，减去500居然不是0，而仍然是500，殊不知此时客户端B已经回滚了，id为1的用户余额又回到1000，减去500，当然还是500。但现在产生数据不一致了，要想解决这个问题，就要采用读已提交级别的隔离。
READ COMMITED（读已提交）
大多数数据库系统的默认隔离级别都是READ COMMITED（但MySQL不是）。READ COMMITED 满足前面提到的隔离性的简单定义：一个事务开始时，只能看见已经提交的事务所做的修改。换句话说，一个事务从开始到提交之前，所做的任何修改对其他事务都是不可见的。这个级别有时候也叫做不可重复的（nonerepeatable read），因为两次执行同样的查询，可能会得到不一样的结果。
打开一个客户端A，并设置当前事物模式为READ COMMITED（读已提交），查询account的数据
# 客户端A mysql> set session transaction isolation level read committed; Query OK, 0 rows affected (0.00 sec) mysql> start transaction; Query OK, 0 rows affected (0.01 sec) mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 1000 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec)
在客户端A提交事务之前，打开另一个客户端B，同样设置事物模式为READ COMMITED ，更新account表后再读取account的数据
# 客户端B mysql> set session transaction isolation level read committed; Query OK, 0 rows affected (0.00 sec) mysql> start transaction; Query OK, 0 rows affected (0.01 sec) mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 1000 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec) mysql> update account set balance = balance - 500 where id = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 500 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec)
这时，客户端B的事物尚未提交，回到客户端A重新读取account表的数据，可以看到，客户端A所看到的数据还是和之前一样，不会发生之前在事物执行时可以读取到对方修改的值
# 客户端A mysql> set session transaction isolation level read committed; Query OK, 0 rows affected (0.00 sec) mysql> start transaction; Query OK, 0 rows affected (0.01 sec) mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 1000 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec) mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 1000 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec)
但是，如果这时候客户端B提交了事物
# 客户端B mysql> update account set balance = balance - 500 where id = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 500 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec) mysql> commit; Query OK, 0 rows affected (0.02 sec)
那么客户端A重新读取account表的数据，会发现两次读取的数据不一致
# 客户端A mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 1000 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec) mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 500 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec)
读已提交的一个弊病，就是在一个事物中，两次读取可能会读到不一样的结果，要解决这个问题，就要靠下面的可重复读机制了。
REPEATABLE READ（可重复读）
REPEATABLE READ解决了脏读问题。该级别保证了在同一个事务中多次读取同样的记录的结果是一致的。但是，理论上，可重复读隔离级别还是无法解决另一个幻读 （PhantomRead）的问题。所谓幻读，指的是当某个事务（用户a读数据）在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录（数据库在此范围内插入了一条数据），当之前的事务再次读 取该范围的记录时，会产生幻行（Phantom Row）。InnoDB和XtraDB 存储引擎通过多版并发控制（MVCC ,Multivesion Concurrency Control ）解决了幻读问题。
打开客户端A，并设置当前事物模式为REPEATABLE READ（可重复读），查询account表的数据
# 客户端A mysql> set session transaction isolation level repeatable read; Query OK, 0 rows affected (0.00 sec) mysql> start transaction; Query OK, 0 rows affected (0.00 sec) mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 1000 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec)
切换到客户端B，查询account表的数据，更新account表，然后提交事物，再重新读取account表的数据
# 客户端B mysql> set session transaction isolation level repeatable read; Query OK, 0 rows affected (0.00 sec) mysql> start transaction; Query OK, 0 rows affected (0.00 sec) mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 1000 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec) mysql> update account set balance = balance - 500 where id = 1; Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> commit; Query OK, 0 rows affected (0.02 sec) #事物提交后，可以看到account表的数据已被修改 mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 500 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec)
客户端A重新读取account表的数据，和之前的数据做对比，可以发现此时就算客户端B修改了account表的数据并提交事物，但客户端A在一次事物中读取的数据不变
# 客户端A mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 1000 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec) mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 1000 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec)
切换到客户端B，插入一条新数据
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into `account`(`name`,`balance`) values("Rose", 900);
Query OK, 1 row affected (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.06 sec)
mysql> select * from account;
+----+------+---------+
| id | name | balance |
+----+------+---------+
| 1 | Amy | 500 |
| 2 | Tom | 500 |
| 3 | John | 350 |
| 4 | Rose | 900 |
+----+------+---------+
4 rows in set (0.00 sec)
再回到客户端A，仍然查询account表的数据，可以看到数据还是和之前展示的一样
# 客户端A mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 1000 | | 2 | Tom | 500 | | 3 | John | 350 | +----+------+---------+ 3 rows in set (0.00 sec)
SERIALIZABLE（可串行化）
SERIALIZABLE是最高的隔离级别。它通过强制事务串行执行，避免了前面说的幻读问题。简单的来说，SERIALIZABLE会在读的每一行数据上 都加上锁，所以可能导致大量的超时和锁征用问题。实际应用中也很少用到这个隔离级别，只有在非常需要确保数据的一致性而且可以接受没有并发的情况，才可考虑用该级别。
打开客户端A，并设置当前事物模式为SERIALIZABLE，查询account表的数据
# 客户端A mysql> set session transaction isolation level serializable; Query OK, 0 rows affected (0.00 sec) mysql> start transaction; Query OK, 0 rows affected (0.00 sec) mysql> select * from account; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Amy | 500 | | 2 | Tom | 500 | | 3 | John | 350 | | 4 | Rose | 900 | +----+------+---------+ 4 rows in set (0.00 sec)
打开另一个客户端B，同样设置事物模式为SERIALIZABLE，并插入一条记录
# 客户端B
mysql> set session transaction isolation level serializable;
Query OK, 0 rows affected (0.00 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into `account`(`name`,`balance`) values("Lucy", 600);
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
由于客户端A的事物先客户端B操作了account表，因此事物A会对account表产生表锁，事物B无法操作account表，过了事物超时时间，就会抛出异常
| 隔离级别 | 脏读可能性 | 不可重复读可能性 | 幻读可能性 | 加锁读 |
| READ UNCOMMITED | YES | YES | YES | NO |
| READ COMMITED | NO | YES | YES | NO |
| REPEATABLE READ | NO | NO | YES | NO |
| SERIALIZABLE | NO | NO | NO | YES |
死锁
死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。当多个事务试图以不同的顺序锁定资源时，也会产生死锁。多个事物同时锁定同一资源，也会产生死锁。例如，设想下面两个事务同事处理StockPrice表：
# 事务1 START TRANSACTION; UPDATE StockPrice SET close = 45.50 WHERE stock_id = 4 and date = \'2002-05-01\'; UPDATE StockPrice SET close = 19.80 WHERE stock_id = 3 and date = \'2002-05-02\'; COMMIT; # 事务2 START TRANSACTION; UPDATE StockPrice SET high = 20.12 WHERE stock_id = 3 and date= \'2002-05-02\'; UPDATE StockPrice SET high = 47.20 WHERE stock_id = 4 and date = \'2002-05-01;\'
如果凑巧，两个事务都执行了第一条UPDATE语句，更新了一行数据，同时也锁定了该行数据，接着每个事务都尝试去执行第二条UPDATE语句，却发现该行已经被对方锁定，然后两个事务都等待对方释放锁，同时又持有对方需要的锁，则陷入死循环。除非有外部因素介入才可能解除死锁。
为了解决这个问题，数据库系统实现了各种死锁检测和死锁超时机制。越复杂的系统，比如InnoDB存储引擎，越能检测到死锁的循环依赖，并立即返回一个错误。这种解决方式很有效，否则死锁会导致出现非常慢的查询。还有一种解决方式，当查询的时间达到锁等待超时的设定后放弃锁请求，这种方式通常来说不太好。InnoDB目前处理死锁的方法是：将持有最少行级排他锁的事务进行回滚（这是相对比较简单的死锁回滚算法）。
锁的行为和顺序是和存储引擎相关的，以同样的顺序去执行语句时，有些存储引擎会产生死锁，有些则不会。因此死锁的产生有双重原因：有些是因为真正的数据冲突，这种情况通常很难避免，但有些则是完全由于存储引擎的实现方式所导致的。
死锁发生以后，只有部分或者完全回滚其中一个事务，才能打破死锁。对于事务型的系统，这是无法避免的，所以应用程序在设计时必须如何考虑处理死锁。大多数情况下只需要重新执行因死锁回滚的事务即可。
事物日志
事务日志可以帮助提高事务的效率，使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把该修改行为记录到保存在硬盘上的事务日志中，而不是每次都将修改的数据本身写入磁盘。事务日志采用的是追加的方式，因此写日志的操作是磁盘上的一小块区域内的顺序I/O，而不像随机I/O需要在磁盘的多个地方移动磁头，所以采用事务日志的方式相对来说要快的多。事务日志保存到磁盘上之后，内存中被修改的数据在后台可以慢慢地刷回磁盘。目前大多数存储引擎都是这么实现的，我们通常称之为预写式日志，修改数据需要写两次磁盘。
如果数据的修改已经记录到事务日志并持久化，但数据本身没有保存到磁盘上，此时系统崩掉了，存储引擎在重启时会自动恢复这些被修改的数据。具体的恢复方式则随着存储引擎的不同而不同。
MySQL中的事物
MySQL提供了两种事务型的存储引擎：InnoDB和NDB Cluster。另外还有一些第三方存储引擎也支持事物，比较知名的包括XtraDB和PBXT。
自动提交（AUTOCOMMIT）
MySQL默认采用自动提交（AUTOCOMMIT）模式。也就是说，如果不是显式地开始一个事务，则每个查询都会被当做一个事务执行提交操作。在当前连接中，可以通过设置AUTOCOMMIT变量来启用或禁用自动提交模式。
AUTOCOMMIT变量来启动或禁用自动提交模式：
mysql> SHOW VARIABLES LIKE \'AUTOCOMMIT\'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | autocommit | ON | +---------------+-------+ 1 row in set (0.00 sec) mysql> SET AUTOCOMMIT = 1; Query OK, 0 rows affected (0.00 sec)
1或者ON表示启用，0或者OFF表示禁用。当AUTOCOMMIT=0时，所有的查询都是在一个是事务中，直到显式的执行COMMIT提交或者ROLLBACK回滚，该事务结束。同时又开始了另一个新事务。修改AUTOCOMMIT对非事务型的表，比如MyISAM或者内存表，不会有任何影响。对这类表来说，没有COMMIT或者ROLLBACK的概念，也可以说是相当于一直处于AUTOCOMMIT启用的模式。
还有一些命令，在执行之前会强制执行COMMIT提交当前的活动事务。在数据定义语言（DDL）中，如果是会导致大量数据改变的操作，比如ALTER TABLE。另外还有LOCK TABLES等其他语句也会导致同样的效果。如果有需要，请检查对应版本的官方文档来确认所有可能导致自动提交的语句列表
MySQL可以通过执行SET TRANSACTION ISOLATION LEVEL 命令来设置隔离级别。新的隔离级别会在下一个事务开始的时候生效。可以在配置文件中设置整个数据库的隔离级别，也可以只改变当前会话的隔离级别：
set session transaction isolation level read committed;
MySQL能识别所有的4个ANSI隔离级别，InnoDB引擎也支持所有的隔离级别。
在事务中混合使用存储引擎
MySQL服务层不管理事务，事务是由下层的存储引擎实现的。所以在同一个事务中，使用多种存储引擎是不可靠的。如果在事务中混合使用了事务型和非事务型的表（例如InnoDB和MyISAM表）。在正常提交的情况下不会有什么问题。但如果该事务需要回滚，非事务型的表上的变更就无法撤销，这会导致数据库处于不一致的状态，这种情况很难修复，事务的最终结果将无法判定。
在非事务型的表上执行事务相关操作的时候，MySQL通常不会发出提醒，也不会报错。有时候只有回滚的时候才会发出一个警告：“某些非事务型的表上的变更不能被回滚”。但大多数情况下，对非事务型表的操作都不会有提示。
隐式和显式锁定
nnoDB采用的是两阶段锁定协议（two-phase locking protocol）。在事务执行的过程中，随时都可以执行锁定，锁只有在执行COMMIT或ROLLBACK的时候才会释放，并且所有的锁是在同一时刻被释放。这些锁都是隐式锁定，InnoDB会根据隔离级别在需要的时候自动加锁。
另外，InnoDB也支持通过特定的语句进行显式的锁定，这些语句不属于SQL规范：
SELECT ... LOCK IN SHARE MODE SELECT ... FOR UPDATE
MySQL也只支持LOCK TABLES和UNLOCK TABLES语句，这是在服务层实现的，和存储引擎无关。它们有自己的用途，并不能代替事务处理。如果应用需要用到事务，还是应该选择事务型存储引擎。经常可以发现，应用语句将表从MyISAM转换到InnoDB，但还是显式地使用LOCK TABLES语句，这非但没有必要，会严重影响性能，实际上InnoDB的行级锁工作得更好。
LOCK TABLES和事务直接相互影响的话，情况会变得非常复杂。除了在事务中禁用AUTOCOMMIT，可以使用LOCK TABLES外，其他任何时候不要显式地执行LOCK TABLES，不管使用的是什么存储引擎。
以上是关于：MySQL架构与历史的主要内容，如果未能解决你的问题，请参考以下文章