Mysql事务，并发问题，锁机制

1、什么是事务

Transaction，数据库操作序列组成的单个逻辑执行单元，要么全部执行，要么全不执行（同生共死）。事务是数据库运行中的一个逻辑工作单位，由DBMS中的事务管理子系统负责事务的处理。事务需手动启动和结束，事务是 恢复 和 并发控制 的基本单位。

事务是一条或多条数据库操作语句的组合，具备ACID，4个特点。

原子性(A)：要不全部成功，要不全部撤销

隔离性(I)：事务之间相互独立，互不干扰

一致性（C）：数据库正确地改变状态后，数据库的一致性约束没有被破坏

持久性()：事务的提交结果，将持久保存在数据库中

其中，C 是终极目标， AID 是方法手段。

注意事项

事务宜短，避免使用嵌套、while循环、DDL；
避免用户交互操作；

2、什么是并发

数据库支持数据共享，允许多个用户程序并行访问数据，引起并发操作 (Concurrency)，即多用户或多事务对同一数据（ 同一时间间隔 ）进行操作，关键是如何对系统内的多个活动（进程）进行切换。

优缺点
对有限物理资源强制多用户共享，复用提高效率；
数据不一致性，破环数据的完整性；

并发 .vs. 并行 (Parallelism)：
 并行性允许多个程序（同一时刻）在不同的CPU上运行。 从微观角度，并行性是多处理机、多进程在同一时刻同时运行，物理上的同时发生，并发性是单处理机下、多个进程在同一时间间隔内运行，逻辑上的同时发生；从宏观角度，并发是表现为并行的。并行性包含同时性和并发性，并行性是并发性的特例。

2、事务并发会产生什么问题

并发操作破坏事务的隔离性，导致如下问题：

1）第一类丢失更新：在没有事务隔离的情况下，两个事务都同时更新一行数据，但是第二个事务却中途失败退出， 导致对数据的两个修改都失效了。

例如：

   张三的工资为5000，事务A中获取工资为5000，事务B获取工资为5000，汇入100，并提交数据库，工资变为5100，

   随后

   事务A发生异常，回滚了，恢复张三的工资为5000，这样就导致事务B的更新丢失了。

2）脏读：脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。
例如：
　　张三的工资为5000,事务A中把他的工资改为8000,但事务A尚未提交。
　　与此同时，
　　事务B正在读取张三的工资，读取到张三的工资为8000。
　　随后，
　　事务A发生异常，而回滚了事务。张三的工资又回滚为5000。
　　最后，
　　事务B读取到的张三工资为8000的数据即为脏数据，事务B做了一次脏读。

3）不可重复读：是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。
例如：
　　在事务A中，读取到张三的工资为5000，操作没有完成，事务还没提交。
　　与此同时，
　　事务B把张三的工资改为8000，并提交了事务。
　　随后，
　　在事务A中，再次读取张三的工资，此时工资变为8000。在一个事务中前后两次读取的结果并不致，导致了不可重复读。

4）**第二类丢失更新：**不可重复读的特例。有两个并发事务同时读取同一行数据，然后其中一个对它进行修改提交，而另一个也进行了修改提交。这就会造成第一次写操作失效。

例如：

在事务A中，读取到张三的存款为5000，操作没有完成，事务还没提交。
　　与此同时，
　　事务B，存储1000，把张三的存款改为6000，并提交了事务。
　　随后，
　　在事务A中，存储500，把张三的存款改为5500，并提交了事务，这样事务A的更新覆盖了事务B的更新。

5）幻读：是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。
例如：
　　目前工资为5000的员工有10人，事务A读取所有工资为5000的人数为10人。
　　此时，
　　事务B插入一条工资也为5000的记录。
　　这是，事务A再次读取工资为5000的员工，记录为11人。此时产生了幻读。

提醒：
不可重复读的重点是修改，同样的条件，你读取过的数据，再次读取出来发现值不一样了
幻读的重点在于新增或者删除，同样的条件，第 1 次和第 2 次读出来的记录数不一样

3、事务隔离级别，解决什么并发问题，以及存在什么并发问题

（1）READ_UNCOMMITTED
　　这是事务最低的隔离级别，它充许另外一个事务可以看到这个事务未提交的数据。
　　解决第一类丢失更新的问题，但是会出现脏读、不可重复读、第二类丢失更新的问题，幻读 。
（2）READ_COMMITTED
　　保证一个事务修改的数据提交后才能被另外一个事务读取，即另外一个事务不能读取该事务未提交的数据。
　　解决第一类丢失更新和脏读的问题，但会出现不可重复读、第二类丢失更新的问题，幻读问题
（3）REPEATABLE_READ
　　保证一个事务相同条件下前后两次获取的数据是一致的

   解决第一类丢失更新，脏读、不可重复读、第二类丢失更新的问题，但会出幻读。

（4）SERIALIZABLE
　　事务被处理为顺序执行。
　　解决所有问题

提醒：

Mysql默认的事务隔离级别为repeatable_read

4、InnoDB引擎的锁机制

（之所以以InnoDB为主介绍锁，是因为InnoDB支持事务，支持行锁和表锁用的比较多，Myisam不支持事务，只支持表锁）

共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
排他锁（X)：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁。
意向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。
意向排他锁（IX）：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。

说明：

1）共享锁和排他锁都是行锁，意向锁都是表锁，应用中我们只会使用到共享锁和排他锁，意向锁是mysql内部使用的，不需要用户干预。

2）对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁（X)；对于普通SELECT语句，InnoDB不会加任何锁，事务可以通过以下语句显示给记录集加共享锁或排他锁。
共享锁（S）：SELECT * FROM table_name WHERE … LOCK IN SHARE MODE。
排他锁（X)：SELECT * FROM table_name WHERE … FOR UPDATE。

3）InnoDB行锁是通过给索引上的索引项加锁来实现的，因此InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！。

5.封锁协议

在运用 排他锁 和 共享锁 对数据对象加锁时，还需要约定一些规则，例如何时申请 排他锁 或 共享锁、持锁时间、何时释放等。称这些规则为封锁协议（Locking Protocol）。对封锁方式规定不同的规则，就形成了各种不同的封锁协议。不同的封锁协议对应不同的隔离级别。

一级封锁协议（对应read uncommited）
一级封锁协议是：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括正常结束（COMMIT）和非正常结束（ROLLBACK）。

一级封锁协议可防止丢失更新，并保证事务T是可恢复的。

在一级封锁协议中，如果仅仅是读数据不对其进行修改，是不需要加锁的，所以它不能保证可重复读和不读“脏”数据。

二级封锁协议（对应read commited）
二级封锁协议是：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁（瞬间S锁）。

二级封锁协议除防止了丢失更新，还可进一步防止读“脏”数据。

三级封锁协议（对应reapetable read）
三级封锁协议是：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。

三级封锁协议除防止了丢失更新和不读‘脏’数据外，还进一步防止了不可重复读和覆盖更新。

四级封锁协议（对应serialization）
四级封锁协议是对三级封锁协议的增强，其实现机制也最为简单，直接对 事务中 所 读取 或者 更改的数据所在的表加表锁，也就是说，其他事务不能 读写 该表中的任何数据。这样五类并发问题都得以避免！

注：封锁协议和隔离级别并不是严格对应的。

封锁后遗症

活锁 (Live Locks)
  多个事务请求对同一数据封锁，某一事务总是处于等待的现象。事务T1封锁数据R，事务T2请求封锁R，于是T2等待。T3也请求封锁R，当T1释放对R的封锁后系统首先批准了T3的请求，T2仍然等待。然后T4又请求封锁R，当T3释放了对R的封锁后系统又批准了T4的请求，…，T2有可能永远等待。
方法：事务排队，先来先服务。

死锁 (Dead Locks)
  也称阻塞，多个事务交错相互等待对方释放资源，循环依赖对方造成资源读写拥挤堵塞的情况，耗时耗资源。事务T1和T2都需要数据Rl和R2，当前Tl封锁数据R1、T2封锁数据R2；然后T1又请求封锁R2、T2又请求封锁Rl；因T2已封锁R2，故T1等待T2释放R2上的锁，因T1已封锁R1，故T2等待T1释放R1上的锁。由于Tl和T2都没有获得需要的全部数据，所以它们不会结束、只能互相等待。
注：区分正常阻塞和死锁的区别。
原因

系统资源不足，资源分配不当、竞争(不可剥夺)资源；
进程运行推进的顺序不合适；
信号量、临时资源利用不当；
必要条件：缺一不可

互斥条件：Mutual exclusion，在一段时间内某个资源只能被一个进程占用；
请求保持条件：Hold and wait，一个进程因请求资源而阻塞时，同时对已获得的资源保持不放；
不剥夺条件：No pre-emption，不能强行剥夺进程已经获得的资源；
循环等待条件：Circular wait，多个进程形成头尾相接的进程-资源环形链，循环等待资源；

方法：（防 + 治）结合；
   数据库引擎的 死锁监视器 定期主动检测陷入死锁的任务。首先引入 安全状态 ：系统能按某种顺序为每个进程分配所需资源并且依次地运行完毕，反之系统是不安全的。安全状态一定不会发生死锁，不安全状态不一定会发生死锁，死锁时系统一定处于不安全状态。
   按同一顺序访问对象、缩短事务持锁时间(避免事务中的用户交互、使用较低的隔离级别、保持事务简短)、行版本控制、绑定连接均可以有效防止死锁问题，其中绑定会话有利于在同一台服务器上共享相同的事务和锁以实现多个会话之间协调操作。
■ 预防死锁
   实质是破坏产生死锁的四个必要条件。实现简单，但是限制条件严格、资源利用率低，破坏系统的并行性、并发性，降低系统性能。

资源静态分配法：破坏请求和保持条件，进程所需资源一次性分配完毕；
可剥夺资源：破坏不可剥夺条件，系统让资源占有者主动释放资源；
■ 避免死锁
   实质是系统允许前三个条件存在，但是在资源的动态分配过程中，预先计算资源分配的安全性以防止系统进入不安全状态(不会形成环形等待的封闭进程链)，从而避免死锁。支持多进程并行执行。

有序资源分配法：破坏环路等待条件，系统为资源编号，进程按编号升序请求资源，释放则相反；
银行家算法：1968年由Dijkstra E.W提出，针对资源分配。限制条件少、资源利用率高，但开销大；
■  检测和解除死锁
   实质是允许系统在运行过程中发生死锁，但系统可及时检测出死锁的发生并精确确定与死锁有关的进程和资源，然后解除之。
[1]. 检测

首先为每个进程、每个资源指定唯一号码，建立进程等待表和资源分配表；
[2]. 解除

剥夺资源：从其它进程剥夺足够数量的资源给死锁进程；
撤销进程：直接撤消死锁进程或撤销死锁优先级低的进程或撤消回滚代价最小的进程；