mysql事务和锁

mysql中的事务：

在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务。

1. InnoDB事务原理

  • 事务（Transaction）是数据库区别于文件系统的重要特性之一，事务会把数据库从一种一致性状态转换为另一种一致性状态。
  • 在数据库提交时，可以确保要么所有修改都已保存，要么所有修改都不保存

2. 事务（ACID）的特征

事务其实就是并发控制的基本单位，数据库事务的ACID四大特性是事务的基础。

  1. 原子性(Atomicity)：整个事物的所有操作要么全部提交成功，要么全部失败回滚(不会出现部分执行的情况)。回滚可以用回滚日志来实现，回滚日志记录着事务所执行的修改操作，在回滚时反向执行这些修改操作即可。

  2. 一致性(Consistency)：几个并行执行的事务，其执行结果必须与按某一顺序串行执行的结果相一致。

  3. 隔离性(Isolation)：事务的执行不受其他事务的干扰，事务执行的中间结果对其他事务必须是透明的。

  4. 持久性(Durability):  一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

MySQL 默认采用自动提交模式。也就是说，如果不显式使用START TRANSACTION语句来开始一个事务，那么每个查询都会被当做一个事务自动提交。

3. 事务分类

　　3.1 扁平事务

  • 扁平事务（Flat Transactions）是事务类型中最简单但使用最频繁的事务。

  • 在扁平事务中，所有的操作都处于同一层次，由BEGIN/START TRANSACTION开始事务，由COMMIT/ROLLBACK结束且都是原子的，要么都执行，要么都回滚。

　　3.2 链事务

  • 链事务（Chained Transaction）是指一个事务由多个子事务链式组成。
  • 前一个子事务的提交操作和下一个子事务的开始操作合并成一个原子操作
  • 这样，在提交子事务时就可以释放不需要的数据对象，而不必等到整个事务完成后才释放。
  • 链事务中的回滚仅限于当前事务，相当于只能恢复到最近的一个保存节点，而带保存节点的扁平事务能回滚到任意正确的保存点。

链事务与扁平事务的区别：

　　　　　　　　a.链事务中的回滚仅限于当前事务，相当于只能恢复到最近的一个保存节点

　　　　　　　　b.带保存节点的扁平事务能回滚到任意正确的保存点

　　　　　　　　c.带有保存节点的扁平事务中的保存点是易失的，当发生系统崩溃是，所有的保存点都将消失，这意味着当进行恢复时，事务需要从开始处重新执行。

　　3.3 嵌套事务

  • 嵌套事务（Nested Transaction）是一个层次结构框架，由一个顶层事务（top-level transaction）控制着各个层次的事务。
  • 顶层事务之下嵌套的事务成为子事务（subtransaction）,其控制着每一个局部的操作，子事务本身也可以是嵌套事务。
  • 因此，嵌套事务的层次结构可以看成是一颗树。

　　3.4 分布式事务

  • 分布式事务（Distributed Transactions）通常是一个在分布式环境下运行的扁平事务，因此需要根据数据所在位置访问网络中不同节点的数据库资源。
  • 例如一个银行用户从招商银行的账户向工商银行的账户转账1000元，这里需要用到分布式事务，因为不能仅调用某一家银行的数据库就完成任务。

4. 事务的隔离级别

数据库的一致性和隔离性其实是一个需要开发者去权衡的东西，为数据库提供什么样的隔离性层级就决定了数据库的性能以及可以达到什么样的一致性。

SQL标准中定义了四种数据库的事务的隔离级别：

　　4.1 未提交读: 脏读（READ UNCOMMITTED）

  • 事务2查询到的数据是事务1中修改但未提交的数据，但因为事务1回滚了数据
  • 所以事务2查询的数据是不正确的，因此出现了脏读的问题。

　　4.2 提交读: 不可重复读（READ COMMITTED）

　　注：一个事务从开始到提交之前对数据所做的改变对其它事务是不可见的，这样就解决在READ-UNCOMMITTED级别下的脏读问题。

  • 事务2执行update语句但未提交前，事务1的前两个select操作返回结果是相同的。
  • 但事务2执行commit操作后，事务1的第三个select操作就读取到事务2对数据的改变。
  • 导致与前两次select操作返回不同的数据，因此出现了不可重复读的问题。

　　4.3 可重复读: 幻读（REPEATABLE READ）：这是MySQL的默认事务隔离级别

  • 事务每开启一个实例，都会分配一个版本号给它，如果读取的数据行正在被其它事务执行DELETE或UPDATE操作（即该行上有排他锁）

  • 这时该事物的读取操作不会等待行上的锁释放，而是根据版本号去读取行的快照数据（记录在undo log中）

  • 这样，事务中的查询操作返回的都是同一版本下的数据，解决了不可重复读问题。

  • 虽然该隔离级别下解决了不可重复读问题，但理论上会导致另一个问题：幻读（Phantom Read）。

  • 一个事务在执行过程中，另一个事物对已有数据行的更改，MVCC机制可保障该事物读取到的原有数据行的内容相同

  • 但并不能阻止另一个事务插入新的数据行，这就会导致该事物中凭空多出数据行，像出现了幻读一样，这便是幻读问题。

　　4.4 可串行读（SERIALIZABLE） 

  • 这是事务的最高隔离级别，通过强制事务排序，使之不可能相互冲突，就是在每个读的数据行加上共享锁来实现。

  • 在该隔离级别下，可以解决前面出现的脏读、不可重复读和幻读问题，但也会导致大量的超时和锁竞争现象，一般不推荐使用。

mysql中的锁：

1. MyISAM和InnoDB支持的锁类型

  1. 相对其他数据库而言，MySQL的锁机制比较简单，其最显著的特点是不同的存储引擎支持不同的锁机制。

  2.  MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）。

  3. InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。

2. 锁分类

　　2.1 按操作划分：DML锁，DDL锁

　　2.2 按锁的粒度划分：表级锁、行级锁、页级锁

　　2.3 按锁级别划分：共享锁、排他锁

　　2.4 按加锁方式划分：自动锁、显示锁

　　2.5 按使用方式划分：乐观锁、悲观锁

3. MySQL这3种锁的特性

Mysql提供了两种封锁粒度：行级锁以及表级锁。
应该尽量只锁定需要修改的那部分数据，而不是所有的资源。锁定的数据量越少，发生锁争用的可能就越小，系统的并发程度就越高。

  1. 行级锁

  • 行级锁分为共享锁和排它锁,行级锁是Mysql中锁定粒度最细的锁。

  •  InnoDB引擎支持行级锁和表级锁，只有在通过索引条件检索数据的时候，才使用行级锁，否就使用表级锁。

  • 行级锁开销大，加锁慢，锁定粒度最小，发生锁冲突概率最低，并发度最高

　　举例： 只根据主键进行查询，并且查询到数据，主键字段产生行锁。

 1 #### 行锁
 2 '''
 3 client1中执行：
 4     select * from shop where id=1 for update;
 5 clenet2中执行：
 6     select * from shop where id=2 for update;   # 可以正常放回数据
 7     select * from shop where id=1 for update;   # 阻塞
 8 '''
 9 # 可以看到：id是主键，当在client1上查询id=1的数据时候，在client2上查询id=2的数据没问题
10 # 但在client2上查询id=1的数据时阻塞，说明此时的锁时行锁。
11 # 当client1执行commit时，clinet2查询的id=1的命令立即返回数据。
行锁举例

　　2. 表级锁

  • 表级锁分为表共享锁和表独占锁。

  • 表级锁开销小，加锁快，锁定粒度大、发生锁冲突最高，并发度最低

　　举例：根据非主键不含索引（name）进行查询，并且查询到数据，name字段产生表锁。

1 #### 表锁
2 # 可以看到，client1通过非索引的name字段查询到prod11的数据后，在client2查prod**的数据会阻塞，产生表锁。
3 '''
4 client1中执行：
5     select * from shop where name="prod11" for update;
6 clenet2中执行：
7     select * from shop where name="prod**" for update;
8 '''
表锁举例

　　3. 页级锁

  • 页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。

  • 表级锁速度快，但冲突多，行级冲突少，但速度慢。

  • 所以取了折衷的页级，一次锁定相邻的一组记录,BDB支持页级锁。

  • 开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

　　总结：

  1. 表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用；
  2.  而行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理（OLTP）系统。

4. 按使用方式划分：乐观锁、悲观锁的作用

  1. 在并发访问情况下，很有可能出现不可重复读等等读现象。

  2.  为了更好的应对高并发，封锁、时间戳、乐观并发控制(乐观锁)、悲观并发控制(悲观锁)都是并发控制采用的主要技术方式。

　　4.1 悲观锁 写少读多

  1. 悲观锁的实现，往往依靠数据库提供的锁机制

  2. MySQL会对查询结果集中每行数据都添加排他锁，其他线程对该记录的更新与删除操作都会阻塞，排他锁包含行锁、表锁。

  3.  申请前提：没有线程对该结果集中的任何行数据使用排他锁或共享锁，否则申请会阻塞。

　　　　适用场景：悲观锁适合写入频繁的场景。

　　　　注：

　　　　　　首先我们需要set autocommit=0，即不允许自动提交
　　　　　　用法：select * from tablename where id = 1 for update;

　　4.2 乐观锁  读多写少  并发量高 执行效率高

  1. 在更新数据的时候需要比较程序中的库存量与数据库中的库存量是否相等，如果相等则进行更新。
  2. 反之程序重新获取库存量，再次进行比较，直到两个库存量的数值相等才进行数据更新。

5. 按锁级别划分：共享锁、排他锁　　

  1. 排它锁
  • 排它锁又叫写锁 简写为 X 锁，如果事务T对A加上排它锁，则其它事务都不能对A加任何类型的锁。
  • 获准排它锁的事务既能读数据，又能写数据。
  • 用法 ：  SELECT … FOR UPDATE

　　2. 共享锁(share lock)

  • 共享锁又叫读锁 简写为 S 锁，如果事务T对A加上共享锁，则其它事务只能对A再加共享锁，不能加其它锁。

  • 获准共享锁的事务只能读数据，不能写数据。

  • 用法： SELECT … LOCK IN SHARE MODE;

 

posted @ 2020-04-29 16:33  O泡小涵  阅读(241)  评论(0)  编辑  收藏  举报
Live2D