前言：前一篇文章关于事务处理的博文没有写清楚，读起来非常晦涩。非常难理解，所以有整理了一些资料，帮助理解。见谅！
关于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 summary=@A 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' ，仅仅用一个所队列。这样的情况下，写锁和读锁的优先级就一样了。这对一些应用可能有帮助。