网站建设与运营实训总结网站建设有哪几个方面

事务:一条或多条sql语句组成的操作。

比如 我们简单的insert

或者 假如说要进行转账，需要先对某人数据减少，然后再把要转账人数据增多。 这几个sql操作组成在一起叫事务。

 那么我们为什么需要事务呢？(注意不是所有的数据库引擎都支持，像innoDB支持，MyISAM就不支持)

假如说两个人同时抢票，但是仅剩一张票，如果让他们两同时对数据进行--操作，那么票最后会变成负数，所以我们需要事务。

一方面，简化了编程模型，另一方面保证了数据的安全。

那么事务又是如何避免这种情况的呢？

●原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

●一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完 全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工 作。

●隔离性：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务 并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（              Read uncommitted ）、读提交（ read committed）、可重复读（ erializable ） repeatable read）和串行化

●持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

那么事务又是如何操作和体现的呢？

操作:

begin;

xxxxx

xxxx

commit;

那为什么单sql语句的时候没有如上的操作呢？

那是因为mysql自动把我们单sql语句设置了事务自动的创建与提交。

体现与演示:

为了演示先采用read uncommited隔离模式，下面会具体讲几个隔离模式。

一.事务的开始与回滚

可以看到可以通过savepoint设置存档点，并且可以通过rollback进行回滚.

二.事务因程序崩溃而未提交会产生回滚

注意我们只begin了，还没有commit，

可以看到再次上线时候，回到了一开始的状态。反之，若是commit就会持久化保存。

此时若是auto-commit若是OFF，即使是单sql语句，若是没用commit的话，也会回滚。

结论：

只要输入begin或者start transaction，事务便必须要通过commit提交，才会持久化，与是 否设置set autocommit无关。

事务可以手动回滚，同时，当操作异常，MySQL会自动回滚

对于InnoDB 每一条 SQL 语言都默认封装成事务，自动提交。（select有特殊情况，因为 MySQL 有 MVCC ）
从上面的例子，我们能看到事务本身的原子性(回滚)，持久性(commit)

事务的隔离级别

●读未提交【Read Uncommitted】： 在该隔离级别，所有的事务都可以看到其他事务没有提交的 执行结果。（实际生产中不可能使用这种隔离级别的），但是相当于没有任何隔离性，也会有很多 并发问题，如脏读，幻读，不可重复读等，我们上面为了做实验方便，用的就是这个隔离性。

 

●读提交【Read Committed】 ：该隔离级别是大多数数据库的默认的隔离级别（不是 MySQL 默 认的）。它满足了隔离的简单定义:一个事务只能看到其他的已经提交的事务所做的改变。这种隔离 级别会引起不可重复读，即一个事务执行时，如果多次 select， 可能得到不同的结果。

●可重复读【Repeatable Read】： 这是 MySQL 默认的隔离级别，它确保同一个事务，在执行 中，多次读取操作数据时，会看到同样的数据行。但是会有幻读问题。

●串行化【Serializable】: 这是事务的最高隔离级别，它通过强制事务排序，使之不可能相互冲突， 从而解决了幻读的问题。它在每个读的数据行上面加上共享锁，。但是可能会导致超时和锁竞争 （这种隔离级别太极端，实际生产基本不使用

 脏读:一个事务在执行中，读到另一个执行中事务的更新(或其他操作)但是未commit的数据，这种现象叫做脏读

不可重复读:同一个事务内，同样的读取，在不同的时间段 (依旧还在事务操作中！)，读取到了不同的值

总结：

其中隔离级别越严格，安全性越高，但数据库的并发性能也就越低，往往需要在两者之间找一个平 衡点。

不可重复读的重点是修改和删除：同样的条件, 你读取过的数据,再次读取出来发现值不一样了

幻读的重点在于新增：同样的条件, 第1次和第2次读出来的记录数不一样

说明： mysql 默认的隔离级别是可重复读,一般情况下不要修改