mysql 事务自动手动提交模式

默认情况下, MySQL启用自动提交模式（变量autocommit为ON）

如果是全局级别，则需要加global，如果是会话级别，则需要加session，如果都没加，默认是session。

全局变量作用域：服务器每次启动将为所有的全局变量赋初始值，修改全局变量针对于所有的会话（连接）有效，但不能跨重启（重启服务器全局变量恢复为默认值）。

会话变量作用域：仅仅针对于当前会话（连接）有效

查询会话事务提交模式：

show session variables like 'autocommit'

查询全局事务提交模式：

show global variables like 'autocommit'

Value的值为ON，表示autocommit开启。OFF表示autocommit关闭。

set global autocommit=0

set SESSION autocommit=0

禁止自动提交

SET AUTOCOMMIT=0

开启自动提交:

SET AUTOCOMMIT=1

查询 正在执行的事务：

SELECT * FROM information_schema.INNODB_TRX

查看正在锁的事务

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS

查看等待锁的事务

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS

结束正在执行的事务：

使用mysql命令杀掉线程：kill 线程id （trx_mysql_thread_id）

手动提交模式：

BEGIN

SQL；

COMMIT

MySQL通过内部两阶段提交协议来提交事务，如下图

具体实现如下图：

第一阶段 ：InnoDB prepare，持有prepare_commit_mutex，并且write/sync redo log；将rollback设置为Prepared状态，binlog prepare不作任何 *** 作；

第二阶段 ：包含两步，write/sync Binlog及 InnoDB commit (写入COMMIT标记后释放prepare_commit_mutex)；

考虑mysql以binlog的写入与否作为事务提交成功与否的标志，如果 在写入innodb commit标志时崩溃(binglog已经写文件但是还没有提交) ，则恢复时，会重新对commit标志进行写入；此时的事务崩溃恢复过程如下：

1)扫描最后一个Binlog文件，提取其中的xid；

2)InnoDB维持了状态为Prepare的事务链表，将这些事务的xid和Binlog中记录的xid做比较，如果在Binlog中存在，则提交，否则回滚事务。

但其中也会存在2个问题：

并发危机:全局大锁prepare_commit_mutex

Mysql5.6.5前的做法，加锁，串行化

无锁方案：如果能保证binlog write 和  Innodb commit的顺序一致性就可以解决该问题。

性能问题：参数sync_binlog =1 ,innodb_flush_log_at_trx_commit =1时，fsync *** 作频繁

数据持久化到磁盘:调用fsync将缓存中的数据刷新到磁盘（普通硬盘150次/s和SSD 1200次/S），影响TPS；Group Commit *** 作，在多个事务并发时，将等待fsync的多个事务合并为仅调用一次fsync *** 作，以解决innodb fsync的问题，对binlog 的fsync也适用

对上述两个问题的解决：

针对并发问题

Group *** 作，三个阶段都在维护一个队列。第一个进队列的线程称为leader线程，负责对队列里所有线程进行 *** 作；之后进入队列的线程称作follower线程，follower 线程进入队列后睡眠，等待leader完成 *** 作后将他们唤醒。注意：前一个队列leader进入后一个队列时，会把自己原队列的follower全加入进去。

针对一致性问题 

Group commit 分为三个阶段，每个阶段有一个线程在执行。分阶段的目的在于各个阶段可以并发执行，提升效率。

涉及参数说明：

sync_binlog =1 :启用group commit之后，其实已经不是一个事务去刷一次磁盘了，而是一组事务刷一次磁盘。图中1、2分别代表sync_binlog 不同配置下，通知其他线程（如dump线程）binlog 已经更新了，当配置为1时，要严格等到sync完毕之后才会发送广播通知, 如果sync_binlog配的是别的值，MySQL会把通知提前到1的位置

binlog_group_commit_sync_no_delay_count(组提交sync无延迟时间最大event数)及binlog_group_commit_sync_delay(组提交sync延迟时间，单位：毫秒)：一般来说我们认为group commit 中最耗时的 *** 作是sync阶段，于是我们可以在sync阶段在leader真正sync之前进行一个等待，以便让fsync一次性刷新更多的事务。这对需要等待sync 完之后才能进行的 *** 作(比如dump线程）可能有性能提升。

两阶段提交：

MYSQL_BIN_LOG作为协调者

当多个用户访问同一份数据时，一个用户在更改数据的过程中，可能有其他用户同时发起更改请求，为保证数据库记录的更新从一个一致性状态变为另外一个一致性状态，使用事务处理是非常必要的，事务具有以下四个特性：

MySQL 提供了多种事务型存储引擎，如 InnoDB 和 BDB 等，而 MyISAM 不支持事务。为了支持事务，InnoDB 存储引擎引入了与事务处理相关的 REDO 日志和 UNDO 日志，同时事务依赖于 MySQL 提供的锁机制

事务执行时需要将执行的事务日志写入日志文件，对应的文件为 REDO 日志。当每条 SQL 进行数据更新 *** 作时，首先将 REDO 日志写进日志缓冲区。当客户端执行 COMMIT 命令提交时，日志缓冲区的内容将被刷新到磁盘，日志缓冲区的刷新方式或者时间间隔可以通过参数 innodb_flush_log_at_trx_commit 控制

REDO 日志对应磁盘上的 ib_logifleN 文件，该文件默认为 5MB，建议设置为 512MB，以便容纳较大的事务。MySQL 崩溃恢复时会重新执行 REDO 日志的记录，恢复最新数据，保证已提交事务的持久性

与 REDO 日志相反，UNDO 日志主要用于事务异常时的数据回滚，具体内容就是记录数据被修改前的信息到 UNDO 缓冲区，然后在合适的时间将内容刷新到磁盘

假如由于系统错误或者 rollback *** 作而导致事务回滚，可以根据 undo 日志回滚到没修改前的状态，保证未提交事务的原子性

与 REDO 日志不同的是，磁盘上不存在单独的 UNDO 日志文件，所有的 UNDO 日志均存在表空间对应的 .ibd 数据文件中，即使 MySQL 服务启动了独立表空间

在 MySQL 中，可以使用 BEGIN 开始事务，使用 COMMIT 结束事务，中间可以使用 ROLLBACK 回滚事务。MySQL 通过 SET AUTOCOMMIT、START TRANSACTION、COMMIT 和 ROLLBACK 等语句支持本地事务

MySQL 定义了四种隔离级别，指定事务中哪些数据改变其他事务可见、哪些数据该表其他事务不可见。低级别的隔离级别可以支持更高的并发处理，同时占用的系统资源更少

InnoDB 系统级事务隔离级别可以使用以下语句设置：

查看系统级事务隔离级别：

InnoDB 会话级事务隔离级别可以使用以下语句设置：

查看会话级事务隔离级别：

在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。读取未提交的数据称为脏读（Dirty Read），即是：首先开启 A 和 B 两个事务，在 B 事务更新但未提交之前，A 事务读取到了更新后的数据，但由于 B 事务回滚，导致 A 事务出现了脏读现象

所有事务只能看见已经提交事务所做的改变，此级别可以解决脏读，但也会导致不可重复读（Nonrepeatable Read）：首先开启 A 和 B 两个事务，A事务读取了 B 事务的数据，在 B 事务更新并提交后，A 事务又读取到了更新后的数据，此时就出现了同一 A 事务中的查询出现了不同的查询结果

MySQL 默认的事务隔离级别，能确保同一事务的多个实例在并发读取数据时看到同样的数据行，理论上会导致一个问题，幻读（Phontom Read）。例如，第一个事务对一个表中的数据做了修改，这种修改会涉及表中的全部数据行，同时第二个事务也修改这个表中的数据，这次的修改是向表中插入一行新数据，此时就会发生 *** 作第一个事务的用户发现表中还有没有修改的数据行

InnoDB 通过多版本并发控制机制（MVCC）解决了该问题：InnoDB 通过为每个数据行增加两个隐含值的方式来实现，这两个隐含值记录了行的创建时间、过期时间以及每一行存储时间发生时的系统版本号，每个查询根据事务的版本号来查询结果

通过强制事务排序，使其不可能相互冲突，从而解决幻读问题。简而言之，就是在每个读的数据行上加上共享锁实现，这个级别会导致大量的超时现象和锁竞争，一般不推荐使用

为了解决数据库并发控制问题，如走到同一时刻客户端对同一张表做更新或者查询 *** 作，需要对并发 *** 作进行控制，因此产生了锁

共享锁的粒度是行或者元组（多个行），一个事务获取了共享锁以后，可以对锁定范围内的数据执行读 *** 作

排他锁的粒度与共享锁相同，一个事务获取排他锁以后，可以对锁定范围内的数据执行写 *** 作

有两个事务 A 和 B，如果事务 A 获取了一个元组的共享锁，事务 B 还可以立即获取这个元组的共享锁，但不能获取这个元组的排他锁，必须等到事务 A 释放共享锁之后。如果事务 A 获取了一个元组的排他锁，事务 B 不能立即获取这个元组的共享锁，也不能立即获取这个元组的排他锁，必须等到 A 释放排他锁之后

意向锁是一种表锁，锁定的粒度是整张表，分为意向共享锁和意向排他锁。意向共享锁表示一个事务有意对数据上共享锁或者排他锁。有意表示事务想执行 *** 作但还没真正执行

锁的粒度主要分为表锁和行锁

表锁的开销最小，同时允许的并发量也是最小。MyISAM 存储引擎使用该锁机制。当要写入数据时，整个表记录被锁，此时其他读/写动作一律等待。一些特定的动作，如 ALTER TABLE 执行时使用的也是表锁

行锁可以支持最大的并发，InnoDB 存储引擎使用该锁机制。如果要支持并发读/写，建议采用 InnoDB 存储引擎

---