mysql比较重要的事务特性与隔离级别，怎么能够错过对它们的认识和介绍。
1. 事务
事务就是一组原子操作，要么全部执行更新成功，要么全部失败。
ACID(原子性、一致性、隔离性和持久性)
原子性：一个事务必须视作一个不可分割的最小工作单元。
一致性：数据库从一致性的状态转换到另外一个一致性状态，如：用户在执行update 减钱或update 加钱的时候，系统崩溃，数据库里面的数据是没有被修改的。因为事务未被提交。
隔离性：一个事务所做的修改在最终提交之前，对其他事务是不可见的。在update 减100元执行完但未提交，另一个事务看到的余额是未被减少的数据结果。
持久性：一旦数据提交，所做的修改会永远存在数据库中。
实际中，要完全实现ACID，会非常困难，需要做额外很多工作来达到这个效果，而这些额外的工作对用户是不可感知的。
为了更好地理解ACID，以银行账户转账为例：
1 START TRANSACTION;
2 SELECT balance FROM checking WHERE customer_id = 702332;
3 UPDATE checking SET balance = balance - 100.00 WHERE customer_id = 702332;
4 UPDATE savings SET balance = balance + 100.00 WHERE customer_id = 702332;
5 COMMIT;
原子性：要么完全提交（702332的checking余额减少100，savings 的余额增加100），要么完全回滚（两个表的余额都不发生变化）
一致性：这个例子的一致性体现在 100元不会因为数据库系统运行到第3行之后，第4行之前时崩溃而不翼而飞，因为事物还没有提交。
隔离性：允许在一个事务中的操作语句会与其他事务的语句隔离开，比如事务A运行到第3行之后，第4行之前，此时事务B去查询checking余额时，它仍然能够看到在事务A中被减去的100元，因为事务A和B是彼此隔离的。在事务A提交之前，事务B观察不到数据的改变。
持久性：这个很好理解。
事务跟锁一样都会需要大量工作，因此你可以根据你自己的需要来决定是否需要事务支持，从而选择不同的存储引擎。
2. 隔离级别
在SQL 标准中定义了四种隔离级别。
较低的隔离级别通常可以执行更高的并发，系统的开销也是更低的。
READ UNCOMMITED 未提交读
事务中修改了数据，即便是未提交，也被其他事务可见，这样就造成了脏读。脏读会带来很多问题，自己也可以想象之，所以很少使用它。
READ COMMITED 提交读
这是大多数数据库的默认隔离级别，一个事务修改数据但未提交，对其他任何事务都是不可见的。也就是不可重复读
REPATABLE READ 可重复读
解决了脏读的问题，但是不能解决另外一个问题，幻读。所谓幻读，就是当某个事务读取某个范围内的记录时，另外一个事务又在该范围插入了新纪录，当之前的事务再次来读取该范围的数据时，发现还有新数据未被更新，就像产生了幻觉一样，即产生幻行。InnoDB 采取了（MVCC, Multiversion Concurrency Control）解决了幻读的问题。
可重复读是 Mysql 的默认事务隔离级别。
SERIALIZABLE 可串行化
它是最高的隔离界别。它通过强制事务串行化，避免了前面所说的幻读问题。简单的说，就是 SERIALIZABLE 会在读取的每一行数据上都加锁，这样会导致大量的超时和锁竞争的问题。实际上也是很少用它来。
查看隔离级别：SELECT @@tx_isolation
设置mysql的隔离级别：set session transaction isolation level 设置事务隔离级别
2.2 死锁
死锁就不再解释，之前有一篇文章单独介绍了死锁及死锁检测，mysql 解决死锁的方式为，死锁检测和死锁超时机制。
InnoDB 实现的方法是，将持有最少的行级排它锁的事务进行回滚。
死锁可能是正在的数据导致，还有可能是存储引擎的实现方式所致。
一般只需要重新执行因死锁而回滚的事务即可。
2.3 事务日志
修改数据，是修改内存拷贝，再把该修改行为记录到持久化事务日志中，而不是每次将修改的数据本身持久到磁盘中。
2.4 mysql 中的事务
Mysql 提供了两种事务型的存储引擎：InnoDB 和 NDB Cluster。也支持第三方引擎
自动提交 AUTOCOMMIT
Mysql 默认采用自动提交模式，如每个select 语句都被当作一个事务执行提交操作。
对MyISAM 自动提交对此类非事务型引擎不起作用。
3. 多版本并发控制
先来谈谈redo log 和 undo log
1.redo log通常是物理日志，记录的是数据页的物理修改，它用来恢复提交后的物理数据页(有且只能恢复到最后一次提交的位置)。
2.undo用来回滚行记录到某个版本。undo log一般是逻辑日志，记录每行数据。
MVCC (Multiversion Concurrency Control)，即多版本并发控制技术,它使得大部分支持行锁的事务引擎，不再单纯的使用行锁来进行数据库的并发控制，取而代之的是把数据库的行锁与行的多个版本结合起来，只需要很小的开销,就可以实现非锁定读，从而大大提高数据库系统的并发性能
InnoDB是一个多版本存储引擎：它保存有关已更改行的旧版本的信息，以支持并发和回滚等事务功能。此信息存储在表空间中称rollback segment的数据结构中。 InnoDB使用rollback segment中的信息来执行事务回滚中所需的撤消操作。它还使用该信息构建行的早期版本以进行一致读取。
在内部，InnoDB为存储在数据库中的每一行添加三个字段。
●6字节的DB_TRX_ID字段指示插入或更新该行的最后一个事务的事务标识符。此外，删除在内部被视为更新，其中行中的special bit被设置为将其标记为已删除。
●每行还包含一个7字节的DB_ROLL_PTR字段，称为滚动指针。 roll指针指向写入回滚段的undo log记录。如果更新了行，则undo log记录了能重建更新之前数据的所有必要信息。
●6字节的DB_ROW_ID字段包含在插入新行时单调增加的行ID。如果InnoDB自动生成聚簇索引，则索引包含行ID值。否则，DB_ROW_ID列不会出现在任何索引中。
rollback段中的undo logs分为插入和更新undo log。只在事务回滚中才需要插入undo log，并且可以在事务提交后立即丢弃。更新undo log也用于一致性读取，但只有在InnoDB没有分配快照的事务之后才能丢弃它们，在一致读取中可能需要更新undo log中的信息来构建早期版本的数据库行。
在InnoDB多版本控制方案中，当您使用SQL语句删除行时，不会立即从数据库中物理删除该行。 InnoDB在丢弃为删除写入的更新撤消日志记录时，仅物理删除相应的行及其索引记录。此删除操作称为清除，并且速度非常快，通常与执行删除的SQL语句的时间顺序相同。
如果你在表中以大约相同的速率插入和删除少量批次的行，则清除线程可能开始落后，并且由于所有“死”行，表可以变得越来越大，使得所有磁盘都受到限制慢。在这种情况下，通过调整innodb_max_purge_lag系统变量来限制新行操作，并为清除线程分配更多资源。有关更多信息。
多版本控制和二级索引
InnoDB多版本并发控制（MVCC）以不同于聚簇索引的方式处理二级索引。聚集索引中的记录就地更新，其隐藏的系统列指向可以重建早期版本记录的撤消日志条目。与聚簇索引记录不同，二级索引记录不包含隐藏的系统列，也不会就地更新。
更新二级索引列时，旧的二级索引记录将被删除标记，插入新记录，最终清除delete-marked的记录。当二级索引记录被delete-marked或二级索引页面由较新的事务更新时，InnoDB在聚簇索引中查找数据库记录。在聚簇索引中，将检查记录的DB_TRX_ID，如果在启动读取事务后修改了记录，则会从undo log中检索正确的记录版本。
如果二级索引记录被标记为删除或二级索引页面由较新的事务更新，则不使用覆盖索引技术。 InnoDB不是从索引结构返回值，而是在聚簇索引中查找记录。
进行一些实例操作，执行reset master 命令清理所有binlog
新建user表
CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键id',
`name` varchar(20) DEFAULT NULL COMMENT '姓名',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
插入几条数据
INSERT INTO `user` (`name`) VALUES ('zhangsan');
INSERT INTO `user` (`name`) VALUES ('lisi');
INSERT INTO `user` (`name`) VALUES ('wangwu');对于insert:
begin->用排他锁锁定该行->记录redo log->记录undo log->插入当前行的新值，写事务编号。若回滚，回滚时把insert undo log丢弃
对于update：
begin->用排他锁锁定该行->记录redo log->记录undo log->修改当前行的值，写事务编号。若回滚，回滚指针指向undo log中的修改前的行
SELECT
Innodb检查每行数据，确保他们符合两个标准：
1、InnoDB只查找版本早于当前事务版本的数据行(也就是数据行的版本必须小于等于事务的版本)，这确保当前事务读取的行都是事务之前已经存在的，或者是由当前事务创建或修改的行
2、行的删除操作的版本一定是未定义的或者大于当前事务的版本号，确定了当前事务开始之前，行没有被删除
符合了以上两点则返回查询结果。
INSERT
InnoDB为每个新增行记录当前系统版本号（事务id）。
DELETE
InnoDB为删除的每一行，保存当前系统版本号作为删除标识。
UPDATE
InnoDB为插入一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本到原来的行作为行删除标识（special bit）。
执行
update user set name='zhangsan22' where id=1;Binlog的记录
执行
delete from user where id=1;Binlog的记录
对应行插入、更新、删除的过程如下图所示
从官方文档可知，删除时先标记为delete-marked， 之后再通过purge的方式进行删除。
事务提交的时候，也会将该事务对应的undo log放入到删除列表中，未来通过purge来删除。
update分为两种情况：update的列是否是主键列
①如果不是主键列，在undo log中直接反向记录是如何update的。即update是直接进行的。
②如果是主键列，update分两步执行：先删除该行，再插入一行目标行。记住，sql每一事务操作都会产生新的版本（事务id）。
