mysql事物

一、 什么是事务

事务就是一段sql 语句的批处理，但是这个批处理是一个atom（原子） ，不可分割，要么都执行，要么回滚（rollback）都不执行。

二、为什么出现这种技术

为什么要使用事务这个技术呢？ 现在的很多软件都是多用户，多程序，多线程的，对同一个表可能同时有很多人在用，为保持数据的一致性，所以提出了事务的概念。这样很抽象，举个例子：

A 给B 要划钱，A 的账户-1000元， B 的账户就要+1000元，这两个update 语句必须作为一个整体来执行，不然A 扣钱了，B 没有加钱这种情况很难处理（找出原因）。

三、如何在MYSQL 中使用事务

1、谁可以使用

只有InnoDB /BDB　的之类的transaction_safe table 才能支持。

默认的engine MyISAM 是不支持事务的，show engine 可以看到支持的和默认的engine。可以在[mysqld] 加入： default_storage_engine=InnoDB;  InnoDB 就是建立表的默认引擎。

建立InnoDB 表：Create table .... type=InnoDB； Alter table table_name type=InnoDB;（如何查看已有表的类型： show create table table_name)

这样我们就可以在InnoDB 表上进行事务操作了！

2、如何使用

启动事务的方法：

认为分为两种：

1、begin ，rollback,commit .当然有的人用begin /begin work .推荐用START TRANSACTION 是SQL-99标准启动一个事务。

start transaction；

update from account set money=money-100 where name='a';

update from account set money=money+100 where name='b';

commit；

解释： 这样start transaction 手动开启事务，commit 手动关闭事务。

注意：当一个事物commit或者roolback时就结束了，如果再次使用需要再次开启事物

2、默认的时候autocommit=1 自动提交是开启的，所以你可以理解为每条语句一输入到mysql就commit 了。当你 set autocommit=0 时候，你可以这样：

update from account set money=money-100 where name='a';

update from account set money=money+100 where name='b';

commit；

// 默认都不提交，只有手动键入commit 时候才上述都提交。

综述：一般使用１　方法。

四、举例

mysql> select * from employee;

+------------+------------+------------+--------------+

| employeeID | name       | job        | departmentID |

+------------+------------+------------+--------------+

|       6651 | Ajay Patel | Programmer |          128 |

|       7513 | Nora Edwar | Programmer |          128 |

|       9006 | Candy Burn | Systems Ad |          128 |

|       9842 | Ben Smith  | DBA        |           42 |

|       9843 | Pert Park  | DBA        |           42 |

|       9845 | Ben Patel  | DBA        |          128 |

|       9846 | Red Right  | x          |          128 |

|       9847 | Run Wild   | x          |          128 |

|       9848 | Rip This J | x          |          128 |

|       9849 | Rip This J | x          |          128 |

|       9850 | Reader U   | x          |          128 |

set auotcommit =0;

insert into employee values(null,"test1",null,128);

savepoint s1;

insert into employee values(null,"test2",null,128);

savepoint s2;

insert into employee values(null,"test3",null,128);

savepoint s3;

执行完三个插入语句，select * from employee 可以看到三条。如果你想回滚到最初rollback 就是最初什么都没有做的状态。 如果你想回到savepoint s1 的状态（也就是插入一条test1 的那里） rollback to savpoint s1 .  同理什么都可以做了。

附录： 事务的ACID(Atomicity \Consistency \Isolation \Durablility)

A: 事务必须是原子（不可分割），要么执行成功进入下一个状态，要么失败rollback 到最初状态。

C：在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。 这个一般通过外键来约束。

I：一个事务不能知道另外一个事务的执行情况（中间状态）

D：在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

mysql 自己的MyISAM 没有通过acid 测试，但是InnoDB 可以做到。

在分布式的系统中，通常会有多个线程连接到数据库中同时对一个表进行操作(这里的同时并不表示同一个时间点，而是同时竞争cpu的资源，至于如何调度，就要看线程和操作系统如何进行调度了)，这种情况下如果会话的事物设置不当，就会导致数据混乱，常常会出现以下三种情况(假设现在系统中有两个会话A和B，同时对表T_Test操作)：
1.脏读：如果有A向B 做了这个操作：update account set money=money+100 where name='B'；在没有commit 之前B 查询：select money from account where name='B'；找到了没有提交的money ，之后A在此时有rollback ，B 再查询，100 不见了。为了避免提高级别：read committed 。就是只能读取提交后的东东。
2.不可重复读：1中说明的就是我们不能读取一个事务的中间状态。 而重复读是指我们每次读取到的结果都要一直。 这个也是mysql 默认的级别。

mysql>  select @@tx_isolation ;

+-----------------+

| @@tx_isolation  |

+-----------------+

| REPEATABLE-READ |

+-----------------+

3.幻读：在一个事务内读取到了别的事务插入的数据，导致前后读取不一致。和不可重复读的区别是：不可重复读是读取到了别人对表中的某一条记录进行了修改，导致前后读取的数据不一致。  虚读是前后读取到表中的记录总数不一样，读取到了其它事务插入的数据。比如现在有 A 和 B 两个应用程序，他们并发访问了数据库中的某一张表，假设表中有 3 条记录，B 执行查询操作， 第一次查询表得到了 3 条记录。此时 A 对表进行了修改，增加了一条记录，当 B 再次查询表的时候，发现多了一条数据。这种情况就造成了 B 的虚读。但是虚读是不一定每次都发生的，这种情况是不确定的。为了避免虚读，我们可以将事物隔离级别设置为 serializable 如果设置成了这种级别，那么数据库就变成了单线程访问的数据库，导致性能降低很多。

summary：

（1）Serializable：可避免脏读、不可重复读、虚读情况的发生。

（2）Repeatable read：可避免脏读、不可重复读情况的发生。（可重复读，是 mysql 默认的事务隔离级别）

（3）Read committed：可避免脏读情况发生。（读取已提交的数据）

（4）Read uncommitted：最低级别，以上情况均无法保证。（读取到了未提交的数据）

当我们将数据库的隔离级别设置为：Serializable 的时候，虽然可以避免所有并发访问的问题，但是 Serializable 采用的是单线程来解决并发访问的问题，也就是说在某一段时间内，只能有一个用户对数据库进行操作，导致其它用户阻塞。导致数据库的访问性能很差。

1.读未提交（Read Uncommitted）：这种隔离级别可以让当前事务读取到其它事物还没有提交的数据。这种读取应该是在回滚段中完成的。通过上面的分析，这种隔离级别是最低的，会导致引发脏读，不可重复读，和幻读。
2.读已提交（Read Committed）：这种隔离级别可以让当前事务读取到其它事物已经提交的数据。通过上面的分析，这种隔离级别会导致引发不可重复读，和幻读。
3.可重复读取（Repeatable Read）：这种隔离级别可以保证在一个事物中多次读取特定记录的时候都是一样的。通过上面的分析，这种隔离级别会导致引发幻读。
4.串行（Serializable）：这种隔离级别将事物放在一个队列中，每个事物开始之后，别的事物被挂起。同一个时间点只能有一个事物能操作数据库对象。这种隔离级别对于数据的完整性是最高的，但是同时大大降低了系统的可并发性。

五、非InnoDB怎么办？

妈的，肯定有人会说那我mysql 的默认MyISAM 怎么办？ 没有事务这样的事情怎么处理呢？ 这个要用到另外一种技术叫做LOCK ! 实际上实现上边那4 个安全级别的所用的技术就是LOCK ！

我怎么在处理锁的问题上，经常听到：共享锁、排它锁、悲观锁、乐观锁、行级锁、表级锁。

共享锁： 就是在读取数据的时候，给数据添加一个共享锁。共享和共享直接是不冲突的，但是和排他锁是冲突的。

排他锁： 更新数据的时候，安装排他锁，禁止其他一切行为。

场景：老公去在 ATM 上取钱，老婆在柜台存钱，假设这个账户中有 1000 元。老公首先执行查询操作，查询到账户余额为 1000 此时程序将 1000 拿到内存中，老公取了 200 元，程序就执行了更新操作将账户余额改为 800，但是当老公的程序没有 commit 的时候，老婆查询账户，此时账户余额还是 1000 元，老婆存入 200 元，程序执行了更新操作将账户余额改为 1200，然后老公将更新语句提交，接着老婆也将更新语句提交。最后导致的结果就是该账户的余额为 1200，这就是更新丢失的问题。引发更新丢失的根源就是查询上，因为双方都是根据从数据库查询到的数据再对数据库中的数据进行更新的。解决更新丢失有三个方案：(1) 将事务隔离级别设置为最高，采用死锁策略。(2) 采用悲观锁，悲观锁不是数据库中真正的锁，是人们看待事务的态度。(3) 采用乐观锁，乐观锁也不是数据库中真正的锁。

如果我们采用的是第一个方案时，老公进行查询操作，数据库为表增加了共享锁，老婆进行查询操作时数据库也增加了一个共享锁。但是当老公进行更新数据库操作时，由于老婆拿着共享锁，导致老公不能增加排它锁，老婆进行更新操作时，因为老公拿着共享锁，导致老婆也拿不到排它锁，这就发生了死锁现象，你等我，我等你。在 mysql 中，处理死锁的方案是释放掉一方的锁。这样就保证了一方更新成功，但是这种性能极低，因为数据库频繁在解决死锁问题。

悲观锁（更新多，查询少时用）

如果我们采用的是第二个方案时，即采用悲观锁。就是我们在操作数据库时采用悲观的态度，认为别人会在此时并发访问数据库。我们在查询语句中 select * from account where name='aaa' for update; 等于加了排它锁。当老公查询余额的时候，select money from account where name='aaa' for update; 增加了排它锁，老婆查询账户余额的时候， select money from account where name='aaa' for update；也要求对数据库加排它锁，因为老公已经拿到了排它锁，导致老婆不能加锁，所以老婆只有等待老公执行完毕，释放掉锁以后才能继续操作。

乐观锁（更新少，查询多时用）

如果我们采用的是第三个方案时，即采用乐观锁，就是我们在操作数据库的时候会认为没有其它用户并发访问，但是乐观锁也不是完全乐观的，乐观锁是采用版本号的方式进行控制的。在数据库表中有一列版本号。从数据库中查询的时候，将版本号也查询过来，在进行更新操作的时候，将版本号加1，查询条件的版本号还是查询过来的版本号。比如，老公执行查询操作的时候，select money,version from account where name='aaa'; 假设此时查询到的版本号为 0，老公在进行更新操作的时候 update account set money=money+100,version=version+1 where name='aaa' and version=0; 未提交时老婆来查询，查询到的版本号依然是 0，老婆也执行更新操作 update account set money=money+100,version=version+1 where name='aaa' and version=0; 现在老公提交了事务，老婆再提交事务的时候发现版本号为 0 的记录没有了，所以就避免了数据丢失的问题。不过这种情况也导致了多个用户更新操作时，只有一个用户的更新被执行。

行级别的锁：

select * from employee where employeeID=9857 for update;  where 后边是索引列

不是索引列那么就为表级别的锁

源出处：http://blog.chinaunix.net/uid-22606185-id-3252443.html