MySQL事务

一、什么称作事务

一个事务是由一条或者多条对数据库操作的SQL语句组成的不扩容分割的单元，只有当事务中所有的SQL操作都正常执行了，整个事务才会提交到数据库，如果部分事务处理失败，那么整个事务是要回滚到最初的状态，因此事务要么全部提交，要么不提交，不存在部分提交。

二、事务的特征（ACID)

• 原子性(Atomic):事务是一个不可分割的单元，事务必须具有原子性，即要么全部执行，要么不执行，不允许部分执行
• 一致性(Consistency)：一个事务执行之前和之后，数据库中的数据必须保持一致性状态,由于并发操作带来的数据不一致性问题:脏读、不可重复读和幻读。
  例如︰在银行转账时，加入小A给小B转账，小A的账号减1000，则对应小B账号加1000，最整个银行存储金额总数是不变的。
• 隔离性(Isolation)：当两个或者多个事务并发执行时，为了保证数据的安全性，当一个事务内存的操作和其他的事务的操作需要隔离起来，不被其他正在执行的事务所看到，隔离性使得每个事务的更新在提交之前，对于其他的事务是不可见的。
• 持久性(Durability)：事务完成之后，数据库需要保证当前事务的修改时永久性的，即使数据库因为故障出错，也应该恢复数据。

三、事务的使用

• 查看事务:select @@autocommit;
  通过select @@autocommit;可以查看事务状态

mysql> select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
|            1 |
+--------------+

默认为1:表示事务是自动提交 0表示手动提交

• 事务设置:set autocommit
  使用set autocommit=0;进行事务手动提交

1.事务操作

• 开启事务: begin或start transaction
• 事务提交: commit
  当一个或者多个SQL组成的事务需要提交时，就通过commit来操作.
• 事务回滚:rollback
  如果执行的过程中有部分事务执行失败，回滚到事务最初的状态
• 保存点： savepoint point1
savepoint point1;设置一个名称为point1的保存点
  rollback to point1;事务回滚到指定的point1点，而不是最初的保存点。
• 查看当前会话隔离级别:select @@tx_isolation;
• 查看系统的隔离级别：select @@global.tx_isolation;

2.并发事务的问题

2.1.脏读(Dirty read)

A事务读取了B事务尚未提交的更改数据，并在这个读取的脏数据上进行操作。如果这时B事务恰巧进行了回滚事务，那么A事务读取的事务是不被承认的。

2.2.不可重复读(Unrepeatableread)不可重复读

是指A事务读取了B事务已经提交的更改数据。

2.3.幻读(Phantom read)

A事务读取到B事务提交的新增数据，幻象读一般发生在数据统计事务中。
不可重复度和幻读区别：
不可重复读一般针对的是行级别的数据的更改(修改)，不可重复读的重点是修改
幻象读一般针对表级别的新增数据，在统计事务中，两次读取的数据统计不一致，幻读的重点在于新增或者删除。

四、简单了解事务的隔离级别

1.READ-UNCOMMITTED(读取未提交)

最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。

2.READ-COMMITTED(读取已提交)

允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。

3.REPEATABLE-READ(可重复读)

对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。

4.SERIALIZABLE(可串行化)

最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

五、简单了解MVCC

MvCC(Multiversion Concurrency Control)，即多版本并发控制技术

• 读锁:也叫共享锁、S锁，若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S 锁。这保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。
• 写锁:又称排他锁、X锁。若事务T对数据对象A加上X锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的锁。这保证了其他事务在T释放A上的锁之前不能再读取和修改A。
• 表锁︰操作对象是数据表。Mysql大多数锁策略都支持(常见mysql innodb)，是系统开销最低但并发性最低的一个锁策略。事务t对整个表加读锁，则其他事务可读不可写，若加写锁，则其他事务增删改都不行。
• 行级锁︰操作对象是数据表中的一行。是MVCC技术用的比较多的，但在MYISAM用不了，行级锁用mysql的储存引擎实现而不是mysql服务器。但行级锁对系统开销较大，处理高并发较好。
  MvCC特点∶
• 每行数据都存在一个版本，每次数据更新时都更新该版本修改时Copy出当前版本随意修改，各个事务之间无干扰。
• 保存时比较版本号，如果成功（commit），则覆盖原记录﹔失败则放弃copy (rollback)
  Innodb的实现方式是:·事务以排他锁的形式修改原始数据。
• 把修改前的数据存放于undo log，通过回滚指针与主数据关联。
• 修改成功(commit)啥都不做，失败则恢复undo log中的数据（rollback)。

六、事务中的日志

6.1.redo log

在innoDB的存储引擎中，事务日志通过重做(redo)日志和innoDB存储引擎的日志缓冲(InnoDB Log Buffer)实现。事务开启时，事务中的操作，都会先写入存储引擎的日志缓冲中，在事务提交之前，这些缓冲的日志都需要提前刷新到磁盘上持久化，这就是DBA们口中常说的“日志先行”(Write-Ahead Logging)。
InnoDB的redo log 是固定大小的，比如可以配置为一组4个文件，每个文件的大小是1GB，那么这块日志总共就可以记录4GB 的操作。

6.2.undo log

undo log主要为事务的回滚服务。在事务执行的过程中，除了记录redo log，还会记录一定量的undo log。undo log记录了数据在每个操作前的状态，如果事务执行过程中需要回滚，就可以根据undo log进行回滚操作。单个事务的回滚，只会回滚当前事务做的操作，并不会影响到其他的事务做的操作。
redo log其实保证的是事务的持久性和一致性，而undo log则保证了事务的原子性
简单思路：
当delete—条记录时,undo log中会记录一条对应的insert记录。

6.3.binlog

关于mysql主从同步很重要，随着系统应用访问量逐渐增大，高并发下通常会采用mysql集群，主库和从库之间的数据是如何同步，其实就是通过binlog主从同步binlog来实现的。

• Binlog是server层的日志，主要做mysql功能层面的事情
• 与redo日志的区别:
  redo是innodb独有的,binlog是所有引擎都可以使用的。
  redo是物理日志，记录的是在某个数据页上做了什么修改, redo是循环写的，空间会用完，
  binlog是逻辑日志，记录的是这个语句的原始逻辑。binlog是可以追加写的，不会覆盖之前的日志信息。

七、主从复制

mysql主从复制需要三个线程,master (binlog dump thread) , slave (I/o thread , sQL thread)

• master
  (1) binlog dump线程︰当主库中有数据更新时，主库就会根据设置的binlog格式，将更新的事件类型写入到主库的binlog文件中，此时主库会创建log dump线程通知slave有数据更新，当I/O线程请求日志内容时，会将此时的binlog名称和当前更新的位置同时传给slave的I/O线程。
• slave
  (2〉I/O线程︰该线程会连接到master，向log dump线程请求一份指定binlog文件位置的副本，并将请求回来的binlog存到本地的relay log中，relay log和binlog日志一样也是记录了数据更新的事件，它也是按照递增后缀名的方式，产生多个relay log (host_name-relay-bin.qo0001)文件，slave会使用一个index文件（host_name-relay-bin.index)来追踪当前正在使用的relay log文件。
  (3)SQL线程︰该线程检测到relay log有更新后，会读取并在本地做redo操作，将发生在主库的事件在本地重新执行一遍，来保证主从数据同步。此外，如果一个relay log文件中的全部事件都执行完毕，那么SQL线程会自动将该relay log文件删除掉。
  下面是整个复制过程的原理图: