一、事务的概念
所谓事务是指一组相互依赖的操作单元的集合，用来保证对数据库的正确修改，保持数据的完整性，如果一个事物的某个单元操作失败，将取消本次事务的全部操作。
数据库事务必须具备以下特征，即ACID：
- 原子性（Atomicity）：每个事物是一个不可分割的整体，只有所有的操作单元执行成功，整个事务才成功，否则此次事务就失败，所有执行成功的操作单元必须撤销，数据库回到此次事务之前的状态。
- 一致性（Consistency）：在执行一次事务后，关系数据的完整性和业务逻辑的一致性不能被破坏。例如A与B转账结束后，他们的资金总额是不能改变的
- 隔离性（Isolation）：在并发环境中，一个事物所做的修改必须与其他事务所做的修改相隔离、例如一个事物查看的数据必须是其他并发事务修改之前或修改完毕的数据，不能是修改中的数据
- 持久性（Durability）：事务结束后，对数据的修改是永久保存的，即使因系统故障导致重启数据库系统，数据依然是修改后的状态。
特别讲解：
1.MySQL事务范围
（1）mysql的任何一个修改操作sql（insert update delete）事务都是客观伴随的，只不过默认是自动提交，这种情况，一旦执行sql，就自动commit了。
（2）sql可以实现手动提交（关闭自动提交）：
（2.1） start transaction / begin/ set autocimmit = 0
（2.2）执行update/insert/delete sql 但是没有提交到数据库
（2.3）commit 提交到数据库
2、事务的特性
在事务的update、delete会有加： 行锁 ，一定操作到的是真正commit的数据。（select不会加 行锁，故而胀读、不可重复读） 比如:
| session1 | session2 |
| begin set `status` = 3 where id = '201810133735578323223' and `status`= 1 affect num : 1 |
|
| update t_record set `status` = 3 where id = '201810133735578323223' and `status`= 1 |
|
| 这时，事实上这句update是任然存在事务（自动），由于session1对这行还没有的修改还没commit，所以mysql自身存在一个行锁，必须等session1提交后，才释放行锁 | |
| commit session1释放行锁 |
|
| affect num : 0 由于session1提交后不满足where条件，返回受影响行数为0 |
二、事务的隔离级别
1）Serializable（串行化）
采用此隔离级别，一个事物在执行过程中首先将其欲操纵的数据锁定，待事务结束后释放。如果此时另一个事务也要操纵该数据，必须等待前一个事务释放锁定后才能继续进行。两个事物实际上是以串行化方式运行的。
（2）Repeatable Read（可重复读）
采用此隔离级别，一个事物在执行过程中能够看到其他事务已经提交的新插入记录，看不到其他事务对已有记录的修改。
（3）Read Committed（读已提交数据）
采用此隔离级别，一个事物在执行过程中能够看到其他事务已经提交的新插入记录，也能看到其他事务已经提交的对已有记录的修改。
（4）Read Uncommitted（读未提交数据）
采用此隔离级别，一个事物在执行过程中能够看到其他事务未提交的新插入记录，也能看到其他事务未提交的对已有记录的修改。
综上所述可以得出，并非隔离级别越高越好，对于多数应用程序，只需把隔离级别设为Read Committed即可，尽管会存在一些问题。
特别讲解：
| 胀读 | 不可重复读 | 幻读 | 更新丢失 | |
| 未提交读 | 是 | 是 | 是 | 是 |
| 已提交读 | 否 | 是 | 是 | 是 |
| 可重复度（repeatable read ）mysql 默认级别 | 否 | 否 | 是 | 是 |
| 可序列化 | 否 | 否 | 否 | 否 |
胀读：事务1更新记录1，但未提交。事务2 select 到事务1尚未commit的记录1， 并根据记录1做后续操作，则造成未提交数据依赖关系问题（万一事务1回滚了更新记录1呢？）故称胀读。这种隔离级别的并发性最好。防止手段就是在事务1未提交事务的情况下，事务2是禁止读取记录的，当然也降低了并发性。
不可重复读：事务1 读了记录1 ，事务2 更新为记录1' ，这时事务1再次读记录1，记录1已经变成1'了。防止手段就是在事务1未提交的时候，禁止事务2修改记录1，同样也降低了并发性。
幻读：事务1按照条件A查询，事务2新插入数据，并且提交。事务1按照条件A搜索出更多的果集。防止手段就是在事务1未提交的情况下，禁止插入新记录，这样并发性很差
第一类更新丢失（回滚丢失）
| 事务1 | 事务2 |
| 开始事务 | 开始事务 |
| 查询账户1000 | 查询账户1000 |
| 更新账户1000+100=1100 | |
| commit | |
| 更新账户1000-100=900 | |
| rollback | |
| 账户回滚到1000 |
事务1的回滚覆盖了事务2的更新，但在sql标准中，任何隔离级别都是不允许这种情况的，所以无需考虑
第二类更新丢失：
账户余额并发修改，账户原有1000，扣两次100钱，由于并发情况，第一次1000-100=900，第二次1000-100=900。那么第一次的减100的信息就丢失了。更新丢失需要靠应用程序保证。
注意：
（1）在上面业务中，并发线程（事务）几乎同时select到原有账户余额，由于事务1此时并没有执行到update这句，两个事务都是在select，所以避免了脏读的隔离级别也不能解决这个问题。即防止脏读是防止：一个事务刚执行了update，但未commit，另一个事务的select该记录，会被阻塞，那个这个时间颗粒度是事务2的select到事务1的commt，并非整个事务中。
（2）避免了不可重复读的隔离级别也不能解决这个问题，尽管由于事务1还没有commit，事务2执行的update账户操作会被阻塞，但是等到事务2执行是，事务执行的基准任然是1000，并不是900（事务1扣100）。即防止不可重复读是防止：事务1执行过select，但未commit，事务2不能update，会被阻塞，阻塞的时间颗粒度也是事务2的update到事务1的commt，并非整个事务。
三、锁的基本知识
数据库管理系统中采用锁的机制来管理事务，当多个事务同时修改同一数据时，只允许持有锁的事务修改该数据，其他事务只能“排队等待”，直到前一个事务释放其拥有的锁。在处理并发读或者写时，可以通过实现一个由两种类型的锁组成的锁系统来解决问题。这两种类型的锁通常称为读锁（Read Lock）和写锁（Write Lock）。
（1）读锁（Read Lock）
读锁（Read Lock）也称为共享锁（Shared Lock）。它是共享的，或者说是相互不阻塞的。多个客户端在同一时间可以同时读取同一资源，互不干扰。
（2）写锁（Write Lock）
写锁（Write Lock）也称为排他锁（Exclusive Lock）。它是排他的，也就是说一个写锁会阻塞其他的写锁和读锁，这是为了确保在给定的时间里，只有一个用户能执行写入，并防止其他用户读取正在写入的同一资源，保证安全。
读锁与写锁的区别：
| 读锁（Read Lock） |
写锁（Write Lock） |
|
| 读锁（Read Lock） |
兼容 |
不兼容 |
| 写锁（Write Lock） |
不兼容 |
不兼容 |
四、死锁的概念与避免
死锁，即当两个或多个处于不同序列的用户打算同时更新某相同的数据库时，因相互等待对方释放权限而导致双方一直处于等待状态。在实际应用中，两个不同序列的客户打算同时对数据执行操作，极有可能产生死锁。更具体的讲，当两个事务相互等待操作对方释放的所持有的资源，而导致两个事物都无法操作对方持有的资源，这样无期限的等待被称为死锁。
不过，MySQL的InnoDB表处理程序具有检查死锁这一功能，如果该处理程序发现用户在操作过程中产生死锁，该处理程序立刻通过撤销操作来撤销其中一个事物，以便使死锁消失。这样就可以使另外一个事务获取对方所占有的资源而执行逻辑操作。
特别说明：
1. InnoDB的行锁（针对select）
InnoDB有两种形式select行锁（注意：update/delete本身默认就会加行锁）：共享锁、排他锁
1.1>共享锁：select * from table lock in share mode
只是确保该条记录在整个事务中，不被修改（update delete），包括自己session和其它session。其它session修 改会被阻塞，自己session修改会死锁
1.2>排他锁：select * from table for update
保证在整个事务中，其它session不能修改此记录，且在自己session会修改此记录
2.乐观锁和悲观锁
乐观锁利用update/delete 操作本身行锁性质 + 返回受影响行数 + 版本号 实现
悲观锁利用排他锁实现;