데이터베이스 트랜잭션 및 MySQL 트랜잭션 요약

InnoDB는 다음 조건에 따라 각 행 레코드를 확인합니다.

1. InnoDB는 버전이 현재 트랜잭션 버전보다 이전인 데이터 행만 찾습니다. 이렇게 하면 트랜잭션에서 읽은 행이 이전에 이미 존재하는지 확인합니다. 트랜잭션 자체에 의해 삽입되거나 수정된 ​​
2. 행의 삭제 버전 번호가 정의되지 않았거나 현재 트랜잭션 버전 번호보다 큽니다. 이는 트랜잭션이 시작되기 전에 트랜잭션에서 읽은 행이 삭제되지 않았음을 보장합니다. . 위의 두 가지 조건만 충족됩니다.

INSERT

• InnoDB는 새로 삽입된 각 행의 행 버전 번호로 현재 시스템 버전 번호를 저장합니다.

DELETE

• InnoDB는 현재 시스템 버전 번호를 저장합니다. 삭제된 각 행에 대한 행 삭제 식별

UPDATE

• InnoDB는 현재 시스템 버전 번호를 삽입된 새 행의 행 버전 번호로 저장하고, 현재 시스템 버전 번호를 삭제 식별자로 원래 행에 저장합니다.

레벨 4: 직렬화 가능가장 높은 격리 레벨입니다

트랜잭션이 서로 충돌하지 않도록 강제로 주문하여 팬텀 읽기 문제를 해결합니다. 즉, 읽은 각 데이터 행에 공유 잠금을 추가합니다. MySQL 잠금 요약
• 이 수준에서는 다수의 시간 초과 및 잠금 경쟁이 발생할 수 있습니다.

격리 수준 비교

각 특정 데이터베이스가 반드시 위의 4가지 격리 수준을 완전히 구현하지는 않습니다. 예:

• ISO/ANSI SQL92에서 정의한 위의 4가지 격리 수준을 지원합니다. , SQL Server도 "스냅샷"이라는 격리 수준을 지원하지만 엄밀히 말하면 MVCC를 사용하여 구현한 직렬화 가능 격리 수준입니다.

• MySQL은 4가지 격리 수준을 모두 지원하지만 특정 구현에서는 일부 격리 수준에서 MVCC 일관성 읽기와 같은 일부 기능이 있지만 경우에 따라 그렇지 않은 경우도 있습니다.

• Mysql은 set transaction 격리 수준 명령을 실행하여 격리 수준을 설정할 수 있습니다. 새 격리 수준은 다음 트랜잭션이 시작될 때 적용됩니다. 예: 세션 트랜잭션 격리 수준 설정 읽기 커밋;

트랜잭션 로그트랜잭션 로그는 트랜잭션 효율성을 높이는 데 도움이 될 수 있습니다.

트랜잭션 로그를 사용하면 스토리지 엔진은 매번 수정된 데이터 자체를 디스크에 유지하는 대신 하드 디스크에 유지되는 트랜잭션 로그에 수정 동작을 복사한 다음 기록합니다.

트랜잭션 로그는 추가 방식을 사용하므로 로그 쓰기 작업은 디스크의 여러 위치에서 헤드를 이동해야 하는 임의 I/O와 달리 디스크의 작은 영역에서 순차적 I/O이므로 트랜잭션이 사용됩니다. 로깅 방법이 상대적으로 훨씬 빠릅니다.
• 트랜잭션 로그가 유지된 후 메모리의 수정된 데이터는 백그라운드에서 디스크로 천천히 플러시될 수 있습니다.
• 데이터 수정 사항이 트랜잭션 로그에 기록되고 지속되었지만 데이터 자체가 디스크에 다시 기록되지 않아 시스템이 충돌하는 경우 스토리지 엔진은 다시 시작할 때 수정된 데이터 중 이 부분을 자동으로 복원할 수 있습니다.
• 현재 대부분의 스토리지 엔진은 이러한 방식으로 구현됩니다. 일반적으로 이를 미리 쓰기 로깅(Write-Ahead Logging)이라고 합니다.

Mysql의 트랜잭션 구현 원리트랜잭션의 구현은 데이터베이스의 스토리지 엔진을 기반으로 합니다. 스토리지 엔진마다 트랜잭션 지원 수준이 다릅니다. mysql에서 트랜잭션을 지원하는 스토리지 엔진에는 innoDB와 NDB가 있습니다.

동시성 제어

事务的隔离性是通过锁实现，而事务的原子性、一致性和持久性则是通过事务日志实现。说到事务日志，不得不说的就是redo和undo。

1.redo log

在innoDB的存储引擎中，事务日志通过重做(redo)日志和innoDB存储引擎的日志缓冲(InnoDB Log Buffer)实现。事务开启时，事务中的操作，都会先写入存储引擎的日志缓冲中，在事务提交之前，这些缓冲的日志都需要提前刷新到磁盘上持久化，这就是DBA们口中常说的“日志先行”(Write-Ahead Logging)。当事务提交之后，在Buffer Pool中映射的数据文件才会慢慢刷新到磁盘。此时如果数据库崩溃或者宕机，那么当系统重启进行恢复时，就可以根据redo log中记录的日志，把数据库恢复到崩溃前的一个状态。未完成的事务，可以继续提交，也可以选择回滚，这基于恢复的策略而定。

在系统启动的时候，就已经为redo log分配了一块连续的存储空间,以顺序追加的方式记录Redo Log,通过顺序IO来改善性能。所有的事务共享redo log的存储空间，它们的Redo Log按语句的执行顺序，依次交替的记录在一起。如下一个简单示例：

记录1：

记录2：

记录3：

记录4：

记录5：

2.undo log

undo log主要为事务的回滚服务。在事务执行的过程中，除了记录redo log，还会记录一定量的undo log。undo log记录了数据在每个操作前的状态，如果事务执行过程中需要回滚，就可以根据undo log进行回滚操作。单个事务的回滚，只会回滚当前事务做的操作，并不会影响到其他的事务做的操作。

以下是undo+redo事务的简化过程

假设有2个数值，分别为A和B,值为1，2

1. start transaction;

2. 记录 A=1 到undo log;

3. update A = 3；

4. 记录 A=3 到redo log；

5. 记录 B=2 到undo log；

6. update B = 4；

7. 记录B = 4 到redo log；

8. 将redo log刷新到磁盘

9. commit

在1-8的任意一步系统宕机，事务未提交，该事务就不会对磁盘上的数据做任何影响。如果在8-9之间宕机，恢复之后可以选择回滚，也可以选择继续完成事务提交，因为此时redo log已经持久化。若在9之后系统宕机，内存映射中变更的数据还来不及刷回磁盘，那么系统恢复之后，可以根据redo log把数据刷回磁盘。

所以，redo log其实保障的是事务的持久性和一致性，而undo log则保障了事务的原子性。

Mysql中的事务使用

MySQL的服务层不管理事务，而是由下层的存储引擎实现。比如InnoDB。

MySQL支持本地事务的语句：

START TRANSACTION | BEGIN [WORK] COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE] ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE] SET AUTOCOMMIT = {0 | 1}

• START TRANSACTION 或 BEGIN 语句：开始一项新的事务。
• COMMIT 和 ROLLBACK：用来提交或者回滚事务。
• CHAIN 和 RELEASE 子句：分别用来定义在事务提交或者回滚之后的操作，CHAIN 会立即启动一个新事物，并且和刚才的事务具有相同的隔离级别，RELEASE 则会断开和客户端的连接。
• SET AUTOCOMMIT 可以修改当前连接的提交方式， 如果设置了 SET AUTOCOMMIT=0，则设置之后的所有事务都需要通过明确的命令进行提交或者回滚

事务使用注意点：

• 如果在锁表期间，用 start transaction 命令开始一个新事务，会造成一个隐含的 unlock
  tables 被执行。
• 在同一个事务中，最好不使用不同存储引擎的表，否则 ROLLBACK 时需要对非事
  务类型的表进行特别的处理，因为 COMMIT、ROLLBACK 只能对事务类型的表进行提交和回滚。
• 和 Oracle 的事务管理相同，所有的 DDL 语句是不能回滚的，并且部分的 DDL 语句会造成隐式的提交。
• 在事务中可以通过定义 SAVEPOINT（例如：mysql> savepoint test; 定义 savepoint，名称为 test），指定回滚事务的一个部分，但是不能指定提交事务的一个部分。对于复杂的应用，可以定义多个不同的 SAVEPOINT，满足不同的条件时，回滚
  不同的 SAVEPOINT。需要注意的是，如果定义了相同名字的 SAVEPOINT，则后面定义的SAVEPOINT 会覆盖之前的定义。对于不再需要使用的 SAVEPOINT，可以通过 RELEASE SAVEPOINT 命令删除 SAVEPOINT， 删除后的 SAVEPOINT， 不能再执行 ROLLBACK TO SAVEPOINT命令。

自动提交（autocommit）：
Mysql默认采用自动提交模式，可以通过设置autocommit变量来启用或禁用自动提交模式

• 隐式锁定

InnoDB在事务执行过程中，使用两阶段锁协议：

随时都可以执行锁定，InnoDB会根据隔离级别在需要的时候自动加锁；

锁只有在执行commit或者rollback的时候才会释放，并且所有的锁都是在同一时刻被释放。

• 显式锁定

InnoDB也支持通过特定的语句进行显示锁定（存储引擎层）：

select ... lock in share mode //共享锁 select ... for update //排他锁

MySQL Server层的显示锁定：

lock table和unlock table

（更多阅读：MySQL锁总结）

MySQL对分布式事务的支持

分布式事务的实现方式有很多，既可以采用innoDB提供的原生的事务支持，也可以采用消息队列来实现分布式事务的最终一致性。这里我们主要聊一下innoDB对分布式事务的支持。

MySQL 从 5.0.3 开始支持分布式事务，当前分布式事务只支持 InnoDB 存储引擎。一个分布式事务会涉及多个行动，这些行动本身是事务性的。所有行动都必须一起成功完成，或者一起被回滚。

如图，mysql的分布式事务模型。模型中分三块：应用程序（AP）、资源管理器（RM）、事务管理器（TM）:

• 应用程序：定义了事务的边界，指定需要做哪些事务；
• 资源管理器：提供了访问事务的方法，通常一个数据库就是一个资源管理器；
• 事务管理器：协调参与了全局事务中的各个事务。

分布式事务采用两段式提交（two-phase commit）的方式：

• 第一阶段所有的事务节点开始准备，告诉事务管理器ready。
• 第二阶段事务管理器告诉每个节点是commit还是rollback。如果有一个节点失败，就需要全局的节点全部rollback，以此保障事务的原子性。

分布式事务（XA 事务）的 SQL 语法主要包括：

XA {START|BEGIN} xid [JOIN|RESUME]

虽然 MySQL 支持分布式事务，但是在测试过程中，还是发现存在一些问题：
如果分支事务在达到 prepare 状态时，数据库异常重新启动，服务器重新启动以后，可以继续对分支事务进行提交或者回滚得操作，但是提交的事务没有写 binlog，存在一定的隐患，可能导致使用 binlog 恢复丢失部分数据。如果存在复制的数据库，则有可能导致主从数据库的数据不一致。

如果分支事务在执行到 prepare 状态时，数据库异常，且不能再正常启动，需要使用备份和 binlog 来恢复数据，那么那些在 prepare 状态的分支事务因为并没有记录到 binlog，所以不能通过 binlog 进行恢复，在数据库恢复后，将丢失这部分的数据。

如果分支事务的客户端连接异常中止，那么数据库会自动回滚未完成的分支事务，如果此时分支事务已经执行到 prepare 状态， 那么这个分布式事务的其他分支可能已经成功提交，如果这个分支回滚，可能导致分布式事务的不完整，丢失部分分支事务的内容。
总之， MySQL 的分布式事务还存在比较严重的缺陷， 在数据库或者应用异常的情况下，
可能会导致分布式事务的不完整。如果应用对于数据的完整性要求不是很高，则可以考虑使
用。如果应用对事务的完整性有比较高的要求，那么对于当前的版本，则不推荐使用分布式
事务。