数据库事物，隔离级别慢慢深入

从事物开始聊到数据库这是一个慢慢深入的过程，一些基础的东西还是懂，其实理论大家都懂，可能用过，但是在讲出来各种的问题缺陷，你没用的足够多还真难，今天慢慢总结一番，希望给其他同学一些启示

什么是事务？
事务（Transaction）：访问并可能更新数据库中各种数据项的一个程序执行单元（unit），它通常由高级数据库操纵语言或编程语言（如SQL，C++或Java）书写的用户程序的执行所引起。当在数据库中更改数据成功时，在事务中更改的数据便会提交，不再改变。否则，事务就取消或者回滚，更改无效。

事务解释：指要做的或所做的事情
事务本质：一系列操作
事务特性：事务是恢复和并发控制的基本单位。

例子：银行转账操作
一个账户里面增加金额，一个账户里面减少金额。必须要同时成功或同时失败。

事务的属性
事务必须满足四个属性，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），即ACID四种属性。

（1 原子性:
一个事务是一个不可分割的整体，为了保证事务的总体目标，事务必须具有原子性，即当数据修改时，要么全都执行，要么全都不执行。即，不允许事务部分地完成，避免了只执行这些操作的一部分而带来的错误。
（2）一致性
一个事务在执行之前和执行之后，数据库数据必须保持一致性。数据库的一致性状态应该满足模式锁指定的约束条件，那么在完整执行该事务后，数据库仍然处于一致性状态。

例如：银行转账，转账前后两个账户金额之和应保持不变。

（3）隔离性
由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。事务查看数据库时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看中间状态的数据。

例如：对任何一对事务T1和T2，对T1而言，T2要么在T1开始之前已经结束，要么在T1完成之后再开始执行。

（4）持久性
也被称为永久性，事务完成以后，DBMS（数据库管理系统）保证它对数据库中数据的修改是永久性的，当系统或介质发生故障时，该修改也永久保持。持久性一般通过数据库备份与恢复来保证。

并发控制
（1）DBS（数据库系统）一个明显的特点是多个用户共享数据库资源，尤其是多个用户可以同时存取相同数据。

串行控制：如果事务是顺序执行的，即一个事务完成之后，再开始另一事务。
并行控制：如果DBMS可以同时接受多个事务，并且这些事务在时间上可以重叠执行。
（2）并发控制概述
事务是并发控制的基本单位，保证事务ACID的特性是事务处理的重要任务，而并发操作有可能会破坏其ACID特性。

DBMS并发控制机制的责任：对并发操作进行正确调度，保证事务的隔离更一般，确保数据库的一致性。

由于并发操作带来的数据不一致性
如果没有锁定且多个用户同时访问一个数据库，则当他们的事务同时使用相同的数据时可能会发生问题。由于并发操作带来的数据不一致性包括：丢失数据更新、读“脏”数据（脏读）、不可重复读。

（1）更新丢失
两个事务都同时更新一行数据，一个事务对数据的更新把另一个事务对数据的更新覆盖了。这是因为系统没有执行任何的锁操作，因此并发并没有被隔离开来。

（2）脏读
一个事务读取到了另一事务未提交的数据操作结果。这是相当危险的，因为很可能所有的操作都被回滚。

（3）不可重复读
不可重复读（Non-repeatable Reads）：一个事务对同一行数据重复读取两次，但是却得到了不同的结果。

包括以下情况：

虚读：事务T1读取某一数据后，事务T2对其做了修改，当事务T1再次读取该数据时得到与前一次不同的值。
幻读：事务在操作过程中进行两次查询，第二次查询的结果包含了第一次查询中未出现的数据或者缺少了第一次查询中出现的数据。这是因为在两次查询过程中有另外一个事务插入数据造成的。
事务隔离级别
为了避免上面出现的几种情况，在标准SQL规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理不同。

读未提交（Read Uncommitted）：
只处理更新丢失。如果一个事务已经开始写数据，则不允许其他事务同时进行写操作，但允许其他事务读此行数据。可通过“排他写锁”实现。
读提交（Read Committed）：
处理更新丢失、脏读。读取数据的事务允许其他事务继续访问改行数据，但是未提交的写事务将会禁止其他事务访问改行。可通过“瞬间共享读锁”和“排他写锁”实现。
可重复读取（Repeatable Read）：
处理更新丢失、脏读和不可重复读取。读取数据的事务将会禁止写事务，但允许读事务，写事务则禁止任何其他事务。可通过“共享读锁”和“排他写锁”实现。
序列化（Serializable）：
提供严格的事务隔离。要求失去序列化执行，事务只能一个接一个地执行，不能并发执行。仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。

——————————————————————————————————————————————————————————————————————————————

MYSQL数据库锁机制

MySQL的锁机制比较简单，其最显著的特点是不同的存储引擎支持不同的锁机制。比如，

MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）。
InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。
所有的锁都是绑定在数据库的索引机制上的！！！
首先锁可以分为：

表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。
页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

锁根据模式分为：

共享锁(S)：发生在数据查找之前，多个事务的共享锁之间可以共存

排他锁(X)：发生在数据更新之前，排他锁是一个独占锁，与其他锁都不兼容

更新锁(U)：发生在更新语句中，更新锁用来查找数据，当查找的数据不是要更新的数据时转化为S锁，当是要更新的数据时转化为X锁

意向锁：发生在较低粒度级别的资源获取之前，表示对该资源下低粒度的资源添加对应的锁，意向锁有分为：意向共享锁(IS) ，意向排他锁(IX)，意向更新锁(IU)，共享意向排他锁(SIX)，共享意向更新锁(SIU)，更新意向排他锁(UIX)

意向锁又分为:

意向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。
意向排他锁（IX）：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。

共享锁／排他锁／更新锁一般作用在较低级别上，例如数据行或数据页，意向锁一般作用在较高的级别上，例如数据表或数据。锁是有层级结构的，若在数据行上持有排他锁的时候，则会在所在的数据页上持有意向排他锁. 在一个事务中，可能由于锁持有的时间太长或个数太多，出于节约资源的考虑，会造成锁升级