MySQL的事务(看看也许有帮助呢)

发布时间 2023-12-26 08:50:29作者: JavaBuild

MySQL的事务

一、事务的概念

在MySQL中,只有InnoDB存储引擎才支持事务。
事务的处理用来维护数据库数据的完整性,保证同一个事务里的一批SQL语句,要么全部执行,要么全部不执行。
事务用来管理DDL、DML、DCL操作,比如insert、update、delete语句,默认自动提交,即执行SQL语句后会马上执行commit操作。
显示地开启一个事务必须使用命令begin或者start transaction,或者执行命令set autocommit=0,用来禁止使用当前会话的自动提交。

  • BEGIN或START TRANSACTION:显示地开启一个事务。
  • COMMIT:提交事务,并使已数据库进行的所有修改是永久的。
  • ROLLBACK:回滚,结束用户的事务,并撤销正在进行的所有未提交的修改。

二、事务的并发问题

在事务的并发操作中可能会出现如下的问题:

  • 丢失更新:一个事务更新之后,另外一个事务也对这个数据进行了更新,那么第一个事务的更新就丢失了。
  • 脏读:一个事务读取到了另外一个事务未提交的数据
  • 不可重复读:一个事务因读取到另外一个事务已经提交的数据。导致对同一条记录的读取两次以上的结果不一致。update操作。
  • 幻读:一个事务因读取到另外一个事务已提交的数据,导致对同一张表的读取结果不一致,insert、delete所致。

三、事务的隔离级别

3.1 事务的隔离级别

为了避免以上几种情况的出现,在标准的SQL规范中,定义了4个事务隔离级别,不同隔离级别对事务的处理不同:
四种隔离级别由低到高分别为:

  • Read uncommitted(读未提交):最低隔离界别,任何情况都无法保障
  • Read committed(读已提交):可避免脏读发生
  • Repeated read(可重复读):可避免脏读和不可重复读的发生。Innodb的RR还可以解决幻读,主要原因是GAP锁(间隙锁),只有RR才能使用GAP锁。
  • serializable(串行化):可避免所有情况(MVCC降低为Locaking-Base CC)

3.2 默认隔离级别

大多数数据库的默认隔离级别是Read committed,比如Oracle和DB2等。MySQL数据库的默认隔离级别是Repeatable Read。
在MySQL数据库中查看当前事务的隔离级别:
select @@tx_isolation;
在MySQL中设置事务的隔离级别:

set [glogal|session]transaction isolation level 隔离级别名称;
或者
set tx_isolation='隔离级别名称';

隔离级别越高,越能保障数据的一致性和完整性,但是对并发性能的影响也越大。
对于多数的应用程序,可以把默认隔离级别设置为Read Committed,为避免脏读读取,同时还具有良好的并发性能。在可能出现不可重复读、幻读这些问题的场合,可以由应用程序采用悲观
锁或者乐观锁来控制。

3.3 Mysql的事务流程

以update为例,innodb的事务流程如下:

update upms_user set real_name='测试'where user_name='A001';

1)事务开始
2)对user_name='A001'这条数据上排他锁,并对数据两边临近范围加gap锁,防止别的事务insert新数据,保证隔离性。
3)将需要修改的数据页加载到innodb_buffer_cache中(内存中的一块区域)。
4)记录检索数据到undo log(修改前的数据,用来保证数据的原子性和一致性)。
5)修改user_name='A001'的数据real_name='测试'。记录修改数据信息到redo log(注意,是数据的当前页修改操作信息,而不是修改后的数据,用来保证持久性),redo log处于prepare状态,随时可以提交事务。
6)刷新innodb_buffer_cache中脏数据到底层磁盘,非commit触发,数据库自动操作。
7)记录binlog,写入磁盘。
8)提交事务,把刚才的redo log改提交状态(两阶段提交)
9)事务结束

四、事务日志文件

4.1 undo log

undo用来保存数据更改之前的数据;保证原子性、一致性。InnoDB存储引擎中,还用Undo log来实现多版本并发控制(MVCC)。
undo log的目的就是满足事务的原子性。操作任何数据之前,首先将数据备份到undo log,然后进行数据的修改。
undo log是为了解决回滚问题,如果出现了错误或者用户执行了ROLLBACK语句,系统可以利用undo log中的备份将数据恢复到事务开始之前的状态。

4.2 redo log

数据库先写redo logo,然后才修改buffer cache中的页(修改数据),修改是以页为单位的,所以先写redo才能保证一个大事务commit的时候,redo已经刷新的差不多了。反过来说假如是先改buffer cache中的页,然后再写redo,就可能会由很多redo需要写,因为一个页中可能有很多数据行,而很多数据行产生的redo也可能比较多,那么commit的时候,就可能会有很多redo需要写。
在事务提交前,只需要将redo log持久化即可。不需要将数据持久化,当系统崩溃时,虽然数据没有持久化,但是Redo log已经持久化。系统可以根据redo log的内容,将所有的数据恢复到最新的状态。需要注意的是,事务过程中,先把redo写进redo log buffer中,然后MySQL后台进程page cleaner thread适当的去刷新redo到底层磁盘永久保存。