原文链接：https://blog.csdn.net/qq_34337272/article/details/80611486
事务处理
事务处理是为了解决【现金转账】这类问题，比如，甲要向乙转账1万元。这其实包含了两个动作“甲从自己的账户中扣1万元”以及“向乙的账户存进1万元“。如果“甲从自己的账户中扣1万元”的时候发生错误，就会出现甲扣了这1万元，而乙的账户并没有增加这一万元。为了解决这个问题，方法是将这两件事作为一个事务处理。两件事情都成功了，整个事务才结束。
声明事务开始（BEGIN或者START TRANSACTION）
回滚（ROLLBACK），强制回到最初状态
提交（COMMIT），提交整个事务，此时在回滚，也不会再恢复
自动提交功能
SET AUTOCOMMIT=0，关闭自动提交
SET AUTOCOMMIT=1，开启自动提交
MySQL默认自动提交。
部分回滚
SAVEPOINT 保存点名
ROLLBACK TO SAVEPOINT 保存点名，回滚到保存点处
RELEASE SAVEPOINT 保存点名，撤销保存点
事务处理的利用范围
以下几条SQL语句，执行后将被自动提交，是在事务处理可以利用的范围之外
-
DROP DATABASE
-
DROP TABLE
-
DROP
-
ALTER TABLE
锁与事务处理分离水平
为什么要锁？
平时我们都是只有一个用户操作数据库，但是与数据库进行连接时，并不总是只有一个用户的。例如，购票系统。平常生活中，几乎多个用户同时使用才是这类系统的常态。
锁的粒度
什么叫锁的粒度？
锁的对象的大小，单位通常被称为锁的粒度。
有以下3种锁的粒度：
-
行（记录）：实施了行锁定的情况下，还可以对同一表的其他行进行处理，Mysql中锁定 粒度最小 的一种锁，只针对当前操作的行进行加锁。 行级锁能大大减少数据库操作的冲突。其加锁粒度最小，并发度高，但加锁的开销也最大，加锁慢，会出现死锁。 InnoDB支持的行级锁，包括如下几种。
-
表：实施了表锁定，其他的事务处理只能在这个表被解除后才能对这个表进行操作，Mysql中锁定 粒度最大 的一种锁，对当前操作的整张表加锁，实现简单 ，资源消耗也比较少，加锁快，不会出现死锁 。其锁定粒度最大，触发锁冲突的概率最高，并发度最低，MyISAM和 InnoDB引擎都支持表级锁。
-
数据库
虽然使用行级锁具有粒度小、并发度高等特点，但是表级锁有时候也是非常必要的：
-
事务更新大表中的大部分数据直接使用表级锁效率更高；
-
事务比较复杂，使用行级索很可能引起死锁导致回滚。
锁的类型
按照使用的目的可以将锁分为共享锁和排他锁（行，表都支持）
共享锁（S锁）：又被称为读锁，其他用户可以并发读取数据，但任何事务都不能获取数据上的排他锁，直到已释放所有共享锁。
共享锁(S锁)又称为读锁，若事务T对数据对象A加上S锁，则事务T只能读A；其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这就保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。
排他锁（X锁）：又称为写锁，若事务T对数据对象A加上X锁，则只允许T读取和修改A，其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。它防止任何其它事务获取资源上的锁，直到在事务的末尾将资源上的原始锁释放为止。在更新操作(INSERT、UPDATE 或 DELETE)过程中始终应用排它锁。
两者之间的区别：
-
共享锁（S锁）：如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加排他锁。获取共享锁的事务只能读数据，不能修改数据。
-
排他锁（X锁）：如果事务T对数据A加上排他锁后，则其他事务不能再对A加任任何类型的*。获取排他锁的事务既能读数据，又能修改数据。
另外两个表级锁：IS和IX 当一个事务需要给自己需要的某个资源加锁的时候，如果遇到一个共享锁正锁定着自己需要的资源的时候，自己可以再加一个共享锁，不过不能加排他锁。但是，如果遇到自己需要锁定的资源已经被一个排他锁占有之后，则只能等待该锁定释放资源之后自己才能获取锁定资源并添加自己的锁定。而意向锁的作用就是当一个事务在需要获取资源锁定的时候，如果遇到自己需要的资源已经被排他锁占用的时候，该事务可以需要锁定行的表上面添加一个合适的意向锁。如果自己需要一个共享锁，那么就在表上面添加一个意向共享锁。而如果自己需要的是某行（或者某些行）上面添加一个排他锁的话，则先在表上面添加一个意向排他锁。意向共享锁可以同时并存多个，但是意向排他锁同时只能有一个存在。
InnoDB另外的两个表级锁：
意向共享锁（IS）： 表示事务准备给数据行记入共享锁，事务在一个数据行加共享锁前必须先取得该表的IS锁。
意向排他锁（IX）： 表示事务准备给数据行加入排他锁，事务在一个数据行加排他锁前必须先取得该表的IX锁。
注意：
这里的意向锁是表级锁，表示的是一种意向，仅仅表示事务正在读或写某一行记录，在真正加行锁时才会判断是否冲突。意向锁是InnoDB自动加的，不需要用户干预。 IX，IS是表级锁，不会和行级的X，S锁发生冲突，只会和表级的X，S发生冲突。
InnoDB的锁机制兼容情况如下：
当一个事务请求的锁模式与当前的锁兼容，InnoDB就将请求的锁授予该事务；反之如果请求不兼容，则该事物就等待锁释放。
死锁和避免死锁
InnoDB的行级锁是基于索引实现的，如果查询语句为命中任何索引，那么InnoDB会使用表级锁. 此外，InnoDB的行级锁是针对索引加的锁，不针对数据记录，因此即使访问不同行的记录，如果使用了相同的索引键仍然会出现锁冲突，还需要注意的是，在通过
SELECT ...LOCK IN SHARE MODE;
或
SELECT ...FOR UPDATE;
使用锁的时候，如果表没有定义任何索引，那么InnoDB会创建一个隐藏的聚簇索引并使用这个索引来加记录锁。
此外，不同于MyISAM总是一次性获得所需的全部锁，InnoDB的锁是逐步获得的，当两个事务都需要获得对方持有的锁，导致双方都在等待，这就产生了死锁。 发生死锁后，InnoDB一般都可以检测到，并使一个事务释放锁回退，另一个则可以获取锁完成事务，我们可以采取以上方式避免死锁：
通过表级锁来减少死锁产生的概率； 多个程序尽量约定以相同的顺序访问表（这也是解决并发理论中哲学家就餐问题的一种思路）； 同一个事务尽可能做到一次锁定所需要的所有资源。
MyISAM和InnoDB存储引擎使用的锁：
-
MyISAM采用表级锁(table-level locking)。
-
InnoDB支持行级锁(row-level locking)和表级锁,默认为行级锁
页级锁： MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。页级进行了折衷，一次锁定相邻的一组记录。BDB支持页级锁。开销和加锁时间界于表锁和行锁之间，会出现死锁。锁定粒度界于表锁和行锁之间，并发度一般。