MySQL事务

时间 2019-11-12

标签 mysql 事务栏目 MySQL 繁體版

原文原文链接

1、什么是事务mysql

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

2、为何出现这种技术数据库

为何要使用事务这个技术呢？如今的不少软件都是多用户，多程序，多线程的，对同一个表可能同时有不少人在用，为保持数据的一致性，因此提出了事务的概念。这样很抽象，举个例子：安全

A 给B 要划钱，A 的帐户-1000元， B 的帐户就要+1000元，这两个update 语句必须做为一个总体来执行，否则A 扣钱了，B 没有加钱这种状况很难处理（找出缘由）。多线程

3、如何在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)atom

这样咱们就能够在InnoDB 表上进行事务操做了！

2、如何使用

启动事务的方法：

认为分为两种：

一、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 手动关闭事务。

二、默认的时候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 时候才上述都提交。

综述：通常使用１　方法。

4、举例

mysql> select * from employee;

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

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

| 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）：这种隔离级别将事物放在一个队列中，每一个事物开始以后，别的事物被挂起。同一个时间点只能有一个事物能操做数据库对象。这种隔离级别对于数据的完整性是最高的，可是同时大大下降了系统的可并发性。

5、非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 后边是索引列

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