mysql的事务与锁机制

置顶 已于 2022-05-22 23:41:12 修改
阅读量1.6k 收藏 11
点赞数 6
分类专栏： mysql 文章标签： mysql 数据库 spring
于 2021-03-24 14:35:55 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_45076180/article/details/115172215
版权

文章目录

        
        我们的数据库一般都会并发执行多个事务，多个事务可能会并发的对相同的一批数据进行增删改查操作，可能就会导致我们说的脏写、脏读、不可重复读、幻读这些问题。mysql中可以通过begin、commit等命令开始或者提交一个事务，在使用Spring的@Transitional注解管理事务时，其底层也是使用Aop调用mysql的begin、commit等命令来解决的。

        Mysql默认的事务隔离级别是可重复读，用Spring开发程序时，如果不设置隔离级别默认用Mysql设置的隔离级别，如果Spring设置了就用spring设置的隔离级别

        

1. 事务及其ACID属性

事务是由一组SQL语句组成的逻辑处理单元，具有以下4个属性，通常简称为事务的ACID属性。

  • 原子性(Atomicity) ：事务是一个原子操作，一组事务中的增删改查，要么全都执行成功，要么全都执行失败。在代码中就表现为@Transitional注解包裹住的代码是一个原子操作
  • 一致性(Consistent)：类似于原子性的概念，不过是针对于数据层面。要求在事务开始和完成时,数据都必须保持一致状态。
  • 隔离性(Isolation)：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的。比如A事务读到数据为10，B事务修改数据为5，那么隔离性要求A事务看不到B事务的修改，仍然认为数据是10，继续执行。否则A事务无法读取一个确定的数据，代码就会很混乱，可重复度隔离级别实现了隔离性
  • 持久性(Durable) ：事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持。

        

2. 事务并发带来的问题

  • 脏写
    • 当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题–最后的更新覆盖了由其他事务所做的更新。
  • 脏读
    • 事务A读取到了事务B已经修改但尚未提交的数据，还在这个数据基础上做了操作。此时，如果B事务回滚，A读取的数据变得无效，属于脏数据，A事务后续的操作其实是在操作虚假数据！不符合事务的一致性要求
  • 不可重复读
    • 事务A内部的相同查询语句在不同时刻读出的结果不一致。一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现其读出的数据已经发生了改变、或某些记录已经被删除了！这种现象就叫做“不可重复读”。不符合事务的隔离性
  • 幻读
    • 事务A读取到了事务B提交的新增数据，不符合隔离性 。一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读”。不符合事务的隔离性

        这些问题的本质都是数据库的多事务并发问题，为了解决多事务并发问题，数据库设计了事务隔离级别、锁机制、MVCC多版本并发控制隔离机制，用一整套机制来解决多事务并发问题。接下来逐个解析

        

3. 事务隔离级别

事务的隔离级别分为以下几种
在这里插入图片描述

  • 查看当前数据库的事务隔离级别: show variables like 'tx_isolation';
  • 设置事务隔离级别：set tx_isolation='REPEATABLE-READ';

        数据库的事务隔离越严格，并发带来的问题就越小，但付出的代价也就越大，因为事务隔离实质上就是使事务在一定程度上“串行化”进行，这显然与“并发”是矛盾的。不同的应用对读一致性和事务隔离程度的要求也是不同的，比如许多应用对“不可重复读"和“幻读”并不敏感，可能更关心数据并发访问的能力。所以Mysql为了并发和性能的均衡，默认选择的事务隔离级别是可重复读。下面通过模拟并发来看一下各种隔离级别的作用

先创建一个表account

//创建表account
CREATE TABLE `account` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `balance` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `test`.`account` (`name`, `balance`) VALUES ('lilei', '450');
INSERT INTO `test`.`account` (`name`, `balance`) VALUES ('hanmei', '16000');
INSERT INTO `test`.`account` (`name`, `balance`) VALUES ('lucy', '2400');

        

①：读未提交

  1. 打开一个客户端A，并设置当前事务模式为read uncommitted（读未提交）set tx_isolation='read-uncommitted';，查询表account的初始值：

    客户端A：
    在这里插入图片描述

  2. 在客户端A的事务提交之前，打开另一个客户端B，更新表account：

    客户端B：
    在这里插入图片描述

  3. 这时，虽然客户端B的事务还没提交，但是客户端A就可以查询到B已经更新的数据：

    客户端A：
    在这里插入图片描述

  4. 一旦客户端B的事务因为某种原因回滚，所有的操作都将会被撤销，那客户端A查询到的数据其实就是脏数据：

    客户端B回滚：
    在这里插入图片描述

  5. 在客户端A执行更新语句update account set balance = balance - 50 where id = 1，lilei的balance没有变成350，居然是400
    在这里插入图片描述
    这是什么原因呢？set balance = balance - 50中的balance是数据库中真实的值450。如果使用java代码400-50=350，那这样的话，客户端A打印的就是350了，所以使用set balance = balance - 50这种数据库级别的修改代替java代码，可保证修改操作的正确性！

        

②：读已提交

  1. 打开一个客户端A，并设置当前事务模式为read committed（未提交读）set tx_isolation='read-committed';，查询表account的所有记录：
    在这里插入图片描述

  2. 在客户端A的事务提交之前，打开另一个客户端B，更新表account：
    3.

  3. 这时，客户端B的事务还没提交，客户端A不能查询到B已经更新的数据，解决了脏读问题：
    4.

  4. 客户端B的事务提交
    在这里插入图片描述

  5. 客户端A执行与上一步相同的查询，结果 与上一步不一致，即产生了不可重复读的问题
    在这里插入图片描述

        

③：可重复读

  1. 打开一个客户端A，并设置当前事务模式为repeatable read（可重复读）set tx_isolation='repeatable-read';，查询表account的所有记录
    在这里插入图片描述
  2. 在客户端A的事务提交之前，打开另一个客户端B，更新表account中lilei的balance为350，并提交
    在这里插入图片描述
  3. 在客户端A查询表account的所有记录，与步骤（1）查询结果一致，没有出现不可重复读的问题
    在这里插入图片描述
  4. 在客户端A，接着执行update account set balance = balance - 50 where id = 1，balance直接变成300，因为这里的balacne使用的是，数据库真实的值。数据的一致性倒是没有被破坏。可重复读的隔离级别下使用了MVCC(multi-version concurrency control)机制，select操作不会更新版本号，是快照读（历史版本）；insert、update和delete会更新版本号，是当前读（当前版本）。
    在这里插入图片描述
  5. 重新打开客户端B，插入一条新数据后提交
    在这里插入图片描述
  6. 在客户端A查询表account的所有记录，没有查出新增数据，所以没有出现幻读
    在这里插入图片描述
  7. 验证幻读，在客户端A执行update account set balance=888 where id = 4;能更新成功，再次查询能查到客户端B新增的数据，可重复读隔离级别中出现了幻读
    在这里插入图片描述

④：串行化

串行化 模式下，所有读写操作都会被加上行锁，这种隔离级别并发性极低，开发中很少会用到。

  1. 打开一个客户端A，并设置当前事务模式为serializable，set tx_isolation='serializable'; ，查询表account的初始值，此时id=1这一行数据已被加上行锁，别的事务无法操作！
    在这里插入图片描述
  2. 打开一个客户端B，并设置当前事务模式为serializable，更新相同的id为1的记录会被阻塞等待，更新id为2的记录可以成功。
    在这里插入图片描述

        

4. mysql的锁机制

        mysql中的数据也是一种共享的资源，当并发访问时可能会出现数据一致性问题，所以mysql使用一些锁机制去应对，但锁机制也是影响数据库并发访问性能的一个重要因素。
        

①：锁分类

  • 悲观锁：悲观锁认为当前环境并发量非常大，为了在高并发情况下保证数据一致性，每次操作数据时需要进行加锁。保证安全的同时降低效率！mysql的for update就是一个悲观所
    • 应用：使用synchronized、Lock，来处理高并发下产生线程不安全问题，这样会使其他线程进行挂起等待，从而影响系统吞吐量
    • 悲观锁发生并发冲突，其他线程被挂起等待！
  • 乐观锁：乐观锁i认为当前环境并发较少，或者很难出现并发，这时如果也使用synchronized、Lock等悲观锁去处理，为了偶尔的并发降低每一次请求的效率，显然有些得不偿失。乐观锁采用版本机制对比， 如果有冲突，返回给用户错误的信息。仅返回错误信息相比于悲观锁的用户态和内核态的切换来讲是很快的！
    • 应用：无锁CAS ，mybatis_plus的乐观锁：@version注解标记比较字段。mysql更新时比对版版本号 update ... where version = 1，如果比对成功才能修改，否则提示错误
    • 乐观锁发生并发冲突，返回错误信息或者自旋！与悲观锁的区别就是这点：宁愿返回错误也不要挂起其他线程！
  • 读锁：也叫共享锁，读锁会阻塞其他session的写，但是不会阻塞其他session的读，属于悲观锁
  • 写锁：也叫排它锁，写锁则会把其他session的读和写都阻塞。属于悲观锁
    • MyISAM在执行查询语句SELECT前，会自动给涉及的所有表加读锁,在执行update、insert、delete操作会自动给涉及的表加写锁。
    • InnoDB在执行查询语句SELECT时(非串行隔离级别)，不会加锁。但是update、insert、delete操作会加行锁。
  • 表锁：每次操作锁住整张表。开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低；一般用在整表数据迁移的场景。
  • 行锁：行锁包括了共享锁、排他锁、间隙锁、记录锁、临键锁.，每次操作锁住一行数据。开销大，加锁慢；会出现死锁（事务修改完一行数据不提交，又去修改别的数据，两个事务相互持有锁不释放导致死锁）；锁定粒度最小，发生锁冲突的概率最低，并发度最高。InnoDB支持行级锁，MYISAM不支持。InnoDB是针对索引加的锁，不是针对记录加的锁。 for update 就是mysql的行锁！表示锁住某一行，不允许其他事务读写数据。但for update 如果使用不当会升级成表锁
    • 使用for update查询非索引字段锁会升级为表锁。例如： wherer id = 1 for update ，id为索引，此时为行锁； wherer name = aaa for update ，name不是索引，此时会升级成表锁，锁住整张表，导致其他sql都操作不了数据库！
    • 因为InnoDB的更新会默认加行锁，所以如果对非索引字段更新，行锁也会变表锁。例如：session1 执行update account set balance = 800 where name = 'lilei';，session2 对该表任一行操作都会阻塞住，并且该索引不能失效，否则都会从行锁升级为表锁
    • 范围查询有时会升级为表锁。范围查询会锁上命中的所有间隙， for update也会升级为表锁
    • 查全表也会导致 for update升级为表锁，例如：select * from user for update
  • 间隙锁 （Gap Locks）：锁的就是两个值之间的空隙，在可重复读隔离级别下才会生效。间隙锁在某些情况下可以解决幻读问题。
    假设account表里数据如下
    在这里插入图片描述
    • 那么间隙就有 id 为 (3,10)，(10,20)，(20,正无穷) 这三个区间
    • 在事务A下面执行 update account set name = 'zhuge' where id > 8 and id <18;，不提交事务
    • 由于id > 8 and id <18处于(3,10)，(10,20)这两个区间内，那么由于事务A没有提交，mysql会使用间隙锁锁住(3,20]这个区间内的所有数据。其他事务无法在(3,20]这个区间内插入或修改任何数据。注意最后那个20也是包含在内的，这就是间隙锁！
  • 临键锁（Next-Key Locks）：是行锁与间隙锁的组合。像上面那个例子里的这个(3,20)的这个区间是开区间，理论上其他事务操作id = 20的数据是可以操作的，由于临键锁的存在，id = 20的数据也变为不可操作。临键锁就是把(3,20)的开区间变为闭区间(3,20]；

       
InnoDB的加锁的方式：

       InnoDB行锁是通过给索引上的索引项加锁来实现的，如果不通过索引条件检索数据，那么InnoDB将对表中的所有记录加锁，实际效果跟表锁一样。那如何给索引项加锁：自动加锁。对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁；对于普通SELECT语句，InnoDB不会加任何锁；当然我们也可以使用for update显示的加锁

       

②：mysql不同操作的加锁规则

以下面这个表来进行实验说明，其中：

  • id 是主键索引（唯一索引）
  • b 是普通索引（非唯一索引）
  • a 是普通的列。
CREATE TABLE `t_ab` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `a` int DEFAULT NULL COMMENT '列a',
  `b` int DEFAULT NULL COMMENT '列b',
  PRIMARY KEY (`id`) USING BTREE,
  KEY `idx_a` (`a`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='ab';

在这里插入图片描述

唯一索引等值查询：

  • 当查询的记录是存在的，临键锁 next-key lock 会退化成「记录锁」，只锁住当前记录id=16，其他事务操作不受影响。如下所示：
    在这里插入图片描述

  • 当查询的记录是不存在的，临键锁 next-key lock 会退化成「间隙锁」，锁住当前id区域中，左开右开如：(8,16)区间的数据，但操作 id=16不受影响！如下所示
    在这里插入图片描述

非唯一索引等值查询：

  • 当查询的记录存在时，除了会加 临键锁 next-key lock 外，还额外加间隙锁，也就是会加两把锁。如下会话1的普通索引 b 上共有两个锁，分别是 next-key lock (4,8] 和间隙锁 (8,16) 。

    • 先会对普通索引 b 加上 next-key lock，范围是(4,8];
    • 然后因为是非唯一索引，且查询的记录是存在的，所以还会加上间隙锁，规则是向下遍历到第一个不符合条件的值才能停止，因此间隙锁的范围是(8,16)。
      在这里插入图片描述

  • 当查询的记录不存在时，只会加 临键锁 next-key lock ，然后会退化为间隙锁，也就是只会加一把锁。

    • 由于b = 5 查询记录是不存在的，所以不锁(4,8)区间，但是要加临键锁next-key lock，锁住下一个区间(8,16] ，然后退化成间隙锁(8,16)！
      在这里插入图片描述

范围查询

非唯一索引和主键索引的范围查询的加锁规则不同之处在于：

  • 唯一索引在满足一些条件的时候，临键锁next-key lock 退化为间隙锁和记录锁。

  • 会话 1 加锁变化过程如下：

    • 最开始要找的第一行是 id = 8，因此 next-key lock(4,8]，但是由于 id 是唯一索引，且该记录是存在的，因此会退化成记录锁，也就是只会对 id = 8 这一行加锁；
    • 由于是范围查找，就会继续往后找存在的记录，也就是会找到 id = 16 这一行停下来，然后加 next-key lock (8, 16]，但由于 id = 16 不满足 id < 9，所以会退化成间隙锁，加锁范围变为 (8, 16)。
    • 所以，会话 1 这时候主键索引的锁是记录锁 id=8 和 间隙锁(8, 16)，在这区间内部的所有事务都被阻塞！
      在这里插入图片描述

  • 非唯一索引范围查询，临键锁 next-key lock 不会退化为间隙锁和记录锁。

  • 会话 1 加锁变化过程如下：

    • 最开始要找的第一行是 b = 8，因此 next-key lock(4,8]，但是由于 b 不是唯一索引，并不会退化成记录锁。
    • 但是由于是范围查找，就会继续往后找存在的记录，也就是会找到 b = 16 这一行停下来，然后加 next-key lock (8, 16]，因为是普通索引查询，所以并不会退化成间隙锁。
    • 所以，会话 1 的普通索引 b 有两个 next-key lock，分别是 (4,8] 和(8, 16]。这样，你就明白为什么会话 2 、会话 3 、会话 4 的语句都会被锁住了。
      在这里插入图片描述

       

②：可重复读一定无法防止幻读吗？

       不一定，间隙锁在某些情况下可以解决幻读问题。比如：在可重复读隔离级别下，事务A如果对数据使用了范围操作，且未提交事务时，其他事务如果要操作事务A的范围间隙中的数据，是会被阻塞的，由于其他事务被阻塞无法修改，就有了一点串行化隔离级别的意思，在这种情况下可重复读可以防止幻读！

       

③：行锁升级为表锁的原因

锁主要是加在索引上，如果对非索引字段更新，行锁可能会变表锁

假如有这张表：只有id是主键索引，其他字段均无索引
在这里插入图片描述
现象：

  • 事务A操作：update account set balance = 800 where name = 'lilei';不提交事务
  • 事务B操作时，对该表任一行操作都会阻塞住

原因：

       事务A在更新数据时，为该行数据加了行锁，但是sql执行计划没用到id这个索引列，那么此时的行锁已经进化为表锁，在事务A提交事务之前，针对这张表的操作都会被阻塞住！

结论：

       InnoDB的行锁是针对索引加的锁，不是针对记录加的锁。并且该索引不能失效，否则都会从行锁升级为表锁。

       

④：锁优化建议

  • 尽可能让所有数据操作都通过索引来完成，避免无索引行锁升级为表锁
  • 尽可能减少检索条件范围，避免间隙锁
  • 涉及事务加行锁的sql尽量放在事务最后执行
  • 尽可能使用低级别事务隔离级别
知识分子_
关注
  • 6
    点赞
  • 踩
  • 11
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
MySQL事务和锁
Java大数据联盟
10-17 1375
主要讲解MySQL的隔离级别、事务、锁
MySQL事务与锁
weixin_30797199的博客
05-07 140
MySQL事务与锁 锁的基本概念 　　锁是计算机协调多个进程或线程并发访问某一资源的机制。 　　相对其他数据库而言，MySQL的锁机制比较简单，其最显著的特点是不同的存储引擎支持不同的锁机制。比如，MyISAM存储引擎采用的是表级锁（table-level locking）；BDB存储引擎采用的是页面锁（page-level locking），但也支持表级锁(已过时)；InnoDB存储引擎既支持...
MySQL中的锁
最新发布
choice~的博客
07-18 1086
IS、IX锁是表级锁，它们的提出仅仅为了在之后加表级别的S锁和X锁时可以快速判断表中的记录是否被上锁，以避免用遍历的方式来查看表中有没有上锁的记录。就是说其实IS锁和IX锁是兼容的，IX锁和IX锁是兼容的。我们画个表来看一下。
MySQL 事务和锁
低吟不作语的博客
04-29 759
事务概述 当多个用户访问同一份数据时，一个用户在更改数据的过程中，可能有其他用户同时发起更改请求，为保证数据库记录的更新从一个一致性状态变为另外一个一致性状态，使用事务处理是非常必要的，事务具有以下四个特性： 原子性（Atomicity）：事务中所有操作视为一个原子单位，即对事务所进行的数据修改等操作只能是完全回滚或完全提交 一致性（Consistency）：事务在完成时，必须使用所有的数据从一种一致性变更为另一种一致性状态，所有的变更都必须应用于事务的修改，以确保数据的完整性。事务的一致性由原子性、持.
mysql事务&&锁机制
WbX7342188的博客
10-21 475
mysql事务及锁机制
mysql-事务与锁
登峰小蚁
05-10 2847
文章目录1. 事务1.1 概念1.2 特性1.3 隔离级别-sql标准2. 并发控制2.1 锁是事务拥有的2.2 锁类别2.3 锁粒度2.3.1 行锁2.3.2 表锁3. 不可重复读和幻读的解决3.1 不可重复读3.1.1 现象：[隔离级别](https://blog.csdn.net/wrongyao/article/details/85036882)3.1.2 解决方式3.1.3 具体实现3....
mysql事务及其锁机制
Chaoer
12-27 898
mysql事务及其锁机制1.事务是一条或多条数据库操作语句的组合。四个特性：ACID；原子性；隔离性；一致性；持久性。MySQL 本身不提供事务支持，而是开放了存储引擎接口，由具体的存储引擎来实现，具体来说支持 MySQL 事务的存储引擎就是 InnoDB。存储引擎实现事务的通用方式是基于 redo log 和 undo log。多版本并发控制（重要）： Mysql的事务存储引擎不是简单实用行加锁
mysql事务和锁
weixin_43979902的博客
12-09 223
什么是数据库的事务？ 事务的典型场景 在项目里面，什么地方会开启事务，或者配置了事务？无论是在方法上加注解，还 是配置切面 <tx:advice id="txAdvice" transaction-manager="transactionManager"> <tx:attributes> <tx:method name="save*" rollback-for="Throwable" /> <tx:method name="add*" rollback-for="
mysql事务锁
lucky的专栏
11-05 951
目录 乐观锁 共享锁与排他锁 共享锁 表锁： |--表级锁（锁定整个表） |--页级锁（锁定一页） |--行级锁（锁定一行） |--共享锁（S锁，MyISAM 叫做读锁） |--排他锁（X锁，MyISAM 叫做写锁） |--悲观锁（抽象性，不真实存在这个锁） |--乐观锁（抽象性，不真实存在这个锁）   乐观锁 乐观锁不是数据库自带的，需要我们自己去实现。乐观锁是指操...
Mysql 事务锁
u010648194的博客
03-20 567
一、InnoDB锁的类型 ① S行级共享锁 S锁简单理解就是：运行 select * from l where id = 1; innoDB就会对id = 1的这行数据进行加S锁; ② X行级排它锁 对数据进行修改时，就会对修改的行加X锁。 排它的意思就是：在同一时间内，两个事务不能同时对一条数据进行修改操作，这也是事务的四个特性中的隔离性。 ③ IS 意向共享锁 ④ IX 意向排它锁 怎么理解意向共享锁和意向排它锁? 意向锁是揭示下一层级请求的锁的类型，InnoDB存储引擎中的意向锁都.
mysql事务-锁
yxkong的专栏
07-04 352
接之前的事务系列mysql事务-innodb中的redolog详解innodb中的undolog 详解mysql事务-MVCC通过前面几篇文章，我们知道，并发产生的事务，基本上会有写-写，读-写或写-读，也是由于隔离级别的不同，可能会导致脏读、幻读等问题。在这篇（mysql事务-MVCC）文章中，我们了解到读操作通过多版本并发控制（MVCC）来解决不一致的问题。写操作可以通过加锁来解决。先简单的梳理下并发时，更新记录时的加锁机制。到此，我们挂起。加锁 带来的问题脏读脏页：缓冲池已修改，还未刷新到磁盘；脏数据
mysql——事务以及锁
qq_16803227的博客
06-08 470
一、事务的特性(ACID),原子性，一致性，隔离性，持久性； 二、Mysql的事务隔离级别 1、读未已提交(READ UNCOMMITTED)： 一个事务可以读取到未提交的数据（比如只进行了更新操作），产生脏读，幻度。 2、读已提交(READ COMMITTED)： 事务读取到已经提交的数据，多次select，查询结果不一致，产生幻度。 3、可重复读(REPEATABLE READ) : 一个事务中多次读取数据相同，可能产生幻读，但是mysql的可重复读解决了幻读...
【Mysql事务及锁机制】
luly0630的专栏
02-14 510
一、ACID事务特性 Atomic：多个操作像一个操作一样，成功或失败 Consistent：在数据层面 ，保证全部成功或失败 Isolation：一个事务内的数据不受其他事务的操作所影响 Durable：事务提交完成后，数据的修改是永久的，即使发生故障也能够保持 二、事务隔离级别 概念：脏读 、重复读、幻读 、当前读（读已提交的最新版本） REPEATABLE READ隔离级别：不同事务中查询不到其他事务提交的数据行，但update更新时仍然会生效，更新仍然存在幻读现象。 ...
mysql锁机制和事务_MySql事务和锁的机制
weixin_29997937的博客
01-19 142
一、支持事务的存储引擎在MySql中，只有InnoDB和BDB支持事务；myIsam等是不支持事务的。二、事务的四大特性ACID1.原子性 Atomicity表示我们对数据库的一系列操作，要么全部成功，要么都是失败；有一个失败，就要回滚，使得前面的操作全部失败。实现方式：undo log2.一致性 Consistency表示事务执行的前后都是合法的数据状态，比如主键必须唯一，字段长度符合要求，以及...
Mysql 事务 - 锁
lpfstudy的博客
04-24 214
一件事情完成了一个任务，里面包含了很多的操作 --》事务一个数据库事务由一条或者多条SQL语句构成，它们形成一个逻辑的工作单元，这些SQL语句要么全部执行成功，要么全部执行失败我们的存储引擎Innodb就可以使用事务这个功能。死锁是指两个或多个进程无限期地等待对方释放资源而无法继续执行的情况。简单来说，就是多个进程互相等待对方释放资源，导致所有进程都无法继续执行，形成了一种僵局状态。死锁是操作系统中的一种常见问题，如果不加以处理，会导致系统性能下降甚至崩溃。
c mysql行锁_MySQL事务、表锁、行锁
weixin_39555951的博客
01-19 128
MySQL 使用 SELECT ... FOR UPDATE 做事务写入前的确认以MySQL 的InnoDB 为例，预设的 Tansaction isolation level 为 REPEATABLE READ ，在 SELECT 的读取锁定主要分为两种方式:SELECT ... LOCK IN SHARE MODESELECT ... FOR UPDATE这两种方式在事务(Transacti...
mysql事务与锁机制
07-27
MySQL事务与锁机制是数据库管理系统中重要的概念。事务是一组数据库操作（例如插入、更新、删除等）的执行单元，要么全部成功执行，要么全部回滚。锁机制用于管理并发访问数据库时的数据一致性和并发控制。 在MySQL中，事务由以下四个特性组成，通常简称为ACID： 1. 原子性（Atomicity）：事务中的操作要么全部完成，要么全部回滚，不存在部分完成的情况。 2. 一致性（Consistency）：事务开始和结束时，数据库的状态必须是一致的。即事务执行前后，数据库中的数据必须满足预定义的完整性约束。 3. 隔离性（Isolation）：并发执行的事务之间相互隔离，一个事务的执行不应该受其他事务的影响。 4. 持久性（Durability）：一旦事务提交，其结果应该永久保存在数据库中，即使发生系统故障也不会丢失。 MySQL中的锁机制用于控制对数据的并发访问。主要有两种类型的锁：共享锁（Shared Lock）和排他锁（Exclusive Lock）。共享锁允许多个事务同时读取同一数据，但不允许并发写操作。排他锁则只允许一个事务独占地进行读写操作。 MySQL提供了多种级别的锁，包括表级锁、行级锁和页面锁。表级锁是最粗粒度的锁，对整个表进行加锁；行级锁是最细粒度的锁，只对操作的行进行加锁；页面锁介于表级和行级之间，对一定范围的行进行加锁。 通过合理使用事务和锁机制，可以确保数据库的数据一致性和并发控制，避免脏读、不可重复读和幻读等问题。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值