MySQL具体解释(14)----------事务处理

Posted yxysuanfa

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了MySQL具体解释(14)----------事务处理相关的知识,希望对你有一定的参考价值。

前言:前一篇文章关于事务处理的博文没有写清楚,读起来非常晦涩。非常难理解,所以有整理了一些资料,帮助理解。见谅!

 

关于mysql事务处理学习记

START TRANSACTION

COMMIT

ROLLBACK

语法

 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能够 回滚当前事务,取消其变更。

 

SET AUTOCOMMIT语句能够禁用或启用默认的autocommit模式,用于当前连接。

自选的WORK关键词被支持。用于COMMIT和RELEASE。与CHAIN和RELEASE子句。

 

CHAIN和RELEASE能够被用于对事务完毕进行附加控制。

 

Completion_type系统变量的值决定了默认完毕的性质。

 

AND CHAIN子句会在当前事务结束时。立马启动一个新事务。而且新事务与刚结束的事务有同样的隔离等级。

 

RELEASE子句在终止了当前事务后。会让server断开与当前client的连接。包括NO关键词能够抑制CHAIN或RELEASE完毕。

假设completion_type系统变量被设置为一定的值。使连锁或释放完毕能够默认进行,此时NO关键词实用。

 

默认情况下,MySQL採用autocommit模式执行。这意味着。当您执行一个用于更新(改动)表的语句之后。MySQL立马把更新存储到磁盘中。

 

假设您正在使用一个事务安全型的存储引擎(如InnoDB, BDB或NDB簇)。则您能够使用下面语句禁用autocommit模式:

SET AUTOCOMMIT=0; 通过把AUTOCOMMIT变量设置为零。禁用autocommit模式之后。您必须使用COMMIT把变更存储到磁盘中。或着假设您想要忽略从事务開始进行以来做出的变更。使用ROLLBACK。

 

假设您想要对于一个单一系列的语句禁用autocommit模式。则您能够使用START TRANSACTION语句:

 

START TRANSACTION;

SELECT @A:=SUM(salary) FROM table1 WHERE type=1;

UPDATE table2 SET [email protected] WHERE type=1; COMMIT;

使用START TRANSACTION,autocommit仍然被禁用,直到您使用COMMIT或ROLLBACK结束事务为止。

然后autocommit模式恢复到原来的状态。

 

BEGIN和BEGIN WORK被作为START TRANSACTION的别名受到支持,用于对事务进行初始化。

START TRANSACTION是标准的SQL语法。而且是启动一个ad-hoc事务的推荐方法。

BEGIN语句与BEGIN关键词的使用不同。BEGIN关键词能够启动一个BEGIN...END复合语句。后者不会開始一项事务。

 

您也能够依照例如以下方法開始一项事务:

START TRANSACTION WITH CONSISTENT SNAPSHOT;

WITH CONSISTENT SNAPSHOT子句用于启动一个一致的读取。用于具有此类功能的存储引擎。

 

眼下,该子句仅仅适用于InnoDB。该子句的效果与公布一个START TRANSACTION,后面跟一个来自不论什么InnoDB表的SELECT的效果一样。

 

開始一项事务会造成一个隐含的UNLOCK TABLES被运行。

为了获得最好的结果,事务应仅仅使用由单一事务存储引擎管理的表运行。

否则,会出现下面问题:

 

假设您使用的表来自多个事务安全型存储引擎(比如InnoDB和BDB)。而且事务隔离等级不是SERIALIZABLE,则有可能当一个事务提交时。其他正在进行中的、使用相同的表的事务将仅仅会发生由第一个事务产生的变更。

也就是。用混合引擎不能保证事务的原子性。并会造成不一致。(假设混合引擎事务不常常有,则您能够依据须要使用

SET TRANSACTION ISOLATION LEVEL把隔离等级设置到SERIALIZABLE。)

 

假设您在事务中使用非事务安全型表,则对这些表的不论什么变更被立马存储,不论autocommit模式的状态怎样。

假设您在更新了事务中一个事务表之后。公布一个ROLLBACK语句,则会出现一个ER_WARNING_NOT_COMPLETE_ROLLBACK警告。

对事务安全型表的变更被 回滚,可是对非事务安全型表没有变更。

每一个事务被存储在一个组块中的二进制日志中,在COMMIT之上。被回滚的事务不被计入日志。(例外情况:对非事务表的更改不会被 回滚。假设一个被回滚的事务包含对非事务表的更改,则整个事务使用一个在末端的ROLLBACK语句计入日志,以确保对这些表的更改进行复制。)

 

您能够使用SET TRANSACTION ISOLATION LEVEL更改事务的隔离等级。

 

回滚能够慢速执行。在用户没有明白要求时,也能够进行回滚(比如。当发生错误时)。因此,在明白地和隐含的(ROLLBACK SQL命令)回滚时。SHOW PROCESSLIST会在Stage列中显示Rolling back。用于连接。

 


    事务处理和并发性

1.1.        基础知识和相关概念

1 )所有的表类型都能够使用锁。可是仅仅有 InnoDB 和 BDB 才有内置的事务功能。

2 )使用 begin 開始事务,使用 commit 结束事务。中间能够使用 rollback 回滚事务。

3 )在默认情况下, InnoDB 表支持一致读。

SQL 标准中定义了 4 个隔离级别: read uncommited 。 read commited , repeatable read 。 serializable 。

read uncommited 即脏读。一个事务改动了一行。还有一个事务也能够读到该行。

假设第一个事务运行了回滚,那么第二个事务读取的就是从来没有正式出现过的值。

?

read commited 即一致读。试图通过仅仅读取提交的值的方式来解决脏读的问题,可是这又引起了不可反复读取的问题。

一个事务运行一个查询。读取了大量的数据行。

在它结束读取之前,还有一个事务可能完毕了对数据行的更改。当第一个事务试图再次运行同一个查询,server就会返回不同的结果。

repeatable read 就可以反复读。在一个事务对数据行运行读取或写入操作时锁定了这些数据行。

可是这样的方式又引发了幻想读的问题。

由于仅仅能锁定读取或写入的行,不能阻止还有一个事务插入数据,后期运行相同的查询会产生很多其它的结果。

serializable 模式中,事务被强制为依次运行。这是 SQL 标准建议的默认行为。

4 )假设多个事务更新了同一行。就能够通过回滚当中一个事务来解除死锁。

5 ) MySQL 同意利用 set transaction 来设置隔离级别。

6 )事务仅仅用于 insert 和 update 语句来更新数据表。不能用于对表结构的更改。运行一条更改表结构或 begin 则会马上提交当前的事务。

7 )全部表类型都支持表级锁,可是 MyISAM 仅仅支持表级锁。

8 )有两种类型的表级锁:读锁和写锁。

读锁是共享锁。支持并发读。写操作被锁。

写锁是独占锁,上锁期间其它线程不能读表或写表。

8 )假设要支持并发读写,建议採用 InnoDB 表,由于它是採用行级锁,能够获得很多其它的更新性能。

9 )非常多时候,能够通过经验来评估什么样的锁相应用程序更合适。只是通常非常难说一个锁比别的更好。这全都要根据应用程序来决定。不同的地方可能须要不同的锁。

当前 MySQL 已经支持 ISAM, MyISAM, MEMORY (HEAP) 类型表的表级锁了。 BDB 表支持页级锁, InnoDB 表支持行级锁。

10 ) MySQL 的表级锁都是写锁优先,并且是採用排队机制,这样不会出现死锁的情况。对于 InnoDB 和 BDB 存储引擎来说,是可能产生死锁的。这是由于 InnoDB 会自己主动捕获行锁。 BDB 会在运行 SQL 语句时捕获页锁的。而不是在事务的開始就这么做。

1.2.        不同锁的优缺点及选择

行级锁的长处及选择 :

1 )在非常多线程请求不同记录时降低冲突锁。

2 )事务回滚时降低改变数据。

3 )使长时间对单独的一行记录加锁成为可能。

行级锁的缺点 :

1 )比页级锁和表级锁消耗很多其它的内存。

2 )当在大量表中使用时。比页级锁和表级锁更慢。由于他须要请求很多其它的所资源。

3 )当须要频繁对大部分数据做 GROUP BY 操作或者须要频繁扫描整个表时。就明显的比其他锁更糟糕。

4 )使用更高层的锁的话,就能更方便的支持各种不同的类型应用程序,由于这样的锁的开销比行级锁小多了。

5 )能够用应用程序级锁来取代行级锁。比如 MySQL 中的 GET_LOCK() 和 RELEASE_LOCK() 。

但它们是劝告锁(原文: These are advisory locks ),因此仅仅能用于安全可信的应用程序中。

6 )对于 InnoDB 和 BDB 表, MySQL 仅仅有在指定用 LOCK TABLES 锁表时才使用表级锁。

在这两种表中,建议最好不要使用 LOCK TABLES 。由于 InnoDB 自己主动採用行级锁。 BDB 用页级锁来保证事务的隔离。

表锁的长处及选择:

1 )非常多操作都是读表。

2 )在严格条件的索引上读取和更新。当更新或者删除能够用单独的索引来读取得到时: UPDATE tbl_name SET column=value WHERE unique_key_col=key_value;DELETE FROM tbl_name WHERE unique_key_col=key_value;

3 ) SELECT 和 INSERT 语句并发的运行,可是仅仅有非常少的 UPDATE 和 DELETE 语句。

4 )非常多的扫描表和对全表的 GROUP BY 操作,可是没有不论什么写表。

表锁的缺点:

1 )一个client提交了一个须要长时间执行的 SELECT 操作。

2 )其它client对同一个表提交了 UPDATE 操作。这个client就要等到 SELECT 完毕了才干開始运行。

3 )其它client也对同一个表提交了 SELECT 请求。因为 UPDATE 的优先级高于 SELECT 。所以 SELECT 就会先等到 UPDATE 完毕了之后才開始运行,它也在等待第一个 SELECT 操作。

1.3.        怎样避免锁的资源竞争

1 )让 SELECT 速度尽量快,这可能须要创建一些摘要表。

2 )启动 mysqld 时使用參数 --low-priority-updates 。这就会让更新操作的优先级低于 SELECT 。

这样的情况下,在上面的如果中,第二个 SELECT 就会在 INSERT 之前运行了,并且也无需等待第一个 SELECT 了。

3 )能够运行 SET LOW_PRIORITY_UPDATES=1 命令,指定全部的更新操作都放到一个指定的链接中去完毕。

4 )用 LOW_PRIORITY 属性来减少 INSERT 。 UPDATE 。 DELETE 的优先级。

5 )用 HIGH_PRIORITY 来提高 SELECT 语句的优先级。

6 )从 MySQL 3.23.7 開始,能够在启动 mysqld 时指定系统变量 max_write_lock_count 为一个比較低的值。它能强制暂时地提高表的插入数达到一个特定值后的全部 SELECT 操作的优先级。它同意在 WRITE 锁达到一定数量后有 READ 锁。

7 )当 INSERT 和 SELECT 一起使用出现故障时。能够转而採用 MyISAM 表,它支持并发的 SELECT 和 INSERT 操作。

8 )当在同一个表上同一时候有插入和删除操作时。 INSERT DELAYED 可能会非常实用。

9 )当 SELECT 和 DELETE 一起使用出现故障时, DELETE 的 LIMIT 參数可能会非常实用。

10 )运行 SELECT 时使用 SQL_BUFFER_RESULT 有助于减短锁表的持续时间。

11 )能够改动源码 `mysys/thr_lock.c‘ ,仅仅用一个所队列。这样的情况下,写锁和读锁的优先级就一样了。这对一些应用可能有帮助。

 

 


以上是关于MySQL具体解释(14)----------事务处理的主要内容,如果未能解决你的问题,请参考以下文章

14.Mysql事务控制和锁定

mysql-14-transaction

14 MySQL--事务&函数与流程控制

mysql由浅入深探究----mysql事务详解

MySQL_InnoDB的锁和事务模型

MySQL ACID及四种隔离级别的解释