《MySQL技术内幕》读书笔记07--事务

概述

• 特性：ACID

  • 原子性atomicity：事务中所有数据库操作都执行成功，事务成功，否则数据库回退到事务执行前的状态

  • 一致性consistency：事务将数据库从一种状态转变为下一种一致的状态，数据库的完整性约束没有被破坏

  • 隔离性isolation：事务的隔离性要求每个读写事务的对象对其他事务的操作对象能相互分离

  • 持久性durability：事物一旦提交，其结果就是永久的

• 数据库事务的隔离级别：Oracle READ COMMITED, Innodb READ REPEATABLE

事务分类

扁平事务

• 所有操作都处于同一层次，由BEGIN WORK开始，由COMMIT WORK或ROLLBACK WORK结束

• 每个数据库系统都实现了对扁平事务的支持

• 限制：不能提交或者回滚事务的某一部分，或者分几个步骤提交

带有保存点的扁平事务

• 允许事务在执行过程中回滚到同一事务中较早的一个状态，不会导致所有的操作都无效

• 保存点用来通知系统记住事务当前的状态，使用SAVE WORK 函数来建立

• 保存点在事务内部是递增的，只有执行命令ROLLBACK WORK，才是完全回滚事务

• 当系统发生崩溃时，所有的保存点都将消失，因为保存点是易失的

链事务

• 在提交事务时，释放不需要的数据对象，将必要的处理上下文隐式的传给下一个要开始的事务

• 是指 应该是 将多个事务合并成一个事务，所以事务回滚只能回到最近点，且上一事务结束和下一个事务开始是一个原子操作

• 链事务在执行COMMIT后会释放的当前事务持有的锁

嵌套事务

• 嵌套事务由若干事务组成的一棵树，子树可以是嵌套事务，也可以是扁平事务

• 叶节点一定是扁平事务，子事务既可以提交也可以回滚。但是只有在父事务提交之后子事务才真正提交

• 任一事务的会滚都会引起子事务一同回滚

分布式事务

• 一个分布式环境下的扁平事务，需要根据数据所在位置访问网络中的不同节点（后续详解）

事务的实现

redo

• 重做日志用来实现事务的持久性

• innodb通过Force Log at Commit机制实现事务的持久性，当事务提交时，必须先将事务的所有日志写入到重做日志持久化，待Commit完成之后才算完成

log block

• 重做日志块：重做日志缓存、重做日志文件都是以块的方式进行保存的，每块大小512字节

log group

• 重做日志组，innodb只支持一个log group。是一个逻辑上的概念，没有物理文件对应

undo

• 事务回滚所需的重做日志

• 逻辑日志，只是将数据库逻辑的回复到原来的样子，当innodb回滚时，实际上做的事与之前相反的工作，insert->delete

• MVCC通过undo实现，当用户读取记录时，如果该记录被其他事务占用，当前事务可以通过undo读取之前的行版本信息，实现非锁定读取

• 事务提交后不马上删除undo log，这是因为其他事务通过undo log查询行记录之前的版本（如上），因此事务提交时将undo log放入到一个链表中，是否删除undo log由purge线程决定

• DELETE操作并不直接删除记录，只是将记录标记为已删除，记录最终删除是在purge操作中完成

• update操作：将原纪录标记为已删除，然后新插入一条记录

事务控制语句

• 主要是开始、结束、回滚、创建/删除/回滚保存点

• 在存储过程中使用START TRANSACTION，不用BEGIN

对于事务操作的统计

• TPS：每秒事务的处理能力 = (com_commit+com_rollback)/time，前提是所有的事务都是显示提交的

SHOW GLOBAL STATUS LIKE 'com_commit'   #查看事务的提交数

分布式事务

• InnoDB提供XA事务的支持，通过XA事务来支持分布式事务的实现。全局事务要求参与的所有事物要么都会滚，要么都提交

• XA事务是由一个或者多个资源管理器、一个事务管理器、一个应用程序组成

• 分布式事务使用两段式提交：第一阶段，所有参与全局事务的节点都开始准备，告诉事务管理器主备好提交了。第二阶段，事务管理器告诉资源管理器执行ROLLBACK或COMMIT，如果任何一个节点显示不能提交，那么所有节点回滚

• Mysql内部存在分布式事务，binlog和存储引擎之间采用XA事务

不好的事务习惯

1. 在循环中提交

2. 自动提交事务

3. 自动回滚事务