MySql-两阶段加锁协议 前言 此篇博客主要是讲述MySql(仅限innodb)的两阶段加锁(2PL)协议,而非两阶段提交(2PC)协议,区别如下: 2PL,两阶段加锁协议:主要用于单机事务中的一致性与隔离性...2PC,两阶段提交协议:主要用于分布式事务。 MySql本身针对性能，还有一个MVCC(多版本控制)控制,本文不考虑此种技术，仅仅考虑MySql本身的加锁协议。...什么是两阶段加锁 在一个事务里面，分为加锁(lock)阶段和解锁(unlock)阶段,也即所有的lock操作都在unlock操作之前,如下图所示: ?...两阶段加锁对性能的影响 上面很好的解释了两阶段加锁，现在我们分析下其对性能的影响。...总结 MySql采用两阶段加锁协议实现隔离性和一致性，我们只有深入的去理解这种协议，才能更好的对我们的SQL进行优化，增加系统的吞吐量。
1.什么是两阶段提交？两阶段提交是一种为了始终保持两个独立逻辑体一致的执行方式。...如果要完成提交操作在执行层面被分成了两个部分(prepare->commit),prepare阶段可以理解为询问所有参与者是否已经准备好，commit阶段确认完所有参与者准备完成那么具体执行相关操作。...2.为什么要引入两阶段提交？ 通过两阶段提交保证了当一个事物会涉及多方参与时状态的一致性。...3.mysql的redo的2PC实现逻辑mysql客户端显示输入"commit"时候或者隐式提交都会触发的2PC过程。...set age=18 where id=1执行流程如下：图片innodb在写redolog日志的时候，会先写log buffer，执行阶段就会写，提交阶段就写磁盘(先prepare，后commit阶段)
InnoDB根据二级索引查询并update操作的search阶段加锁进一步分析：
InnoDB update加锁分2个阶段，search阶段加锁和update阶段加锁，本图讲述search阶段加锁： ?
Mysql 的两阶段提交 在 MySQL架构（二）SQL 更新语句是如何执行的？...中说到了 redo log 和 binlog 日志文件，在事务执行过程中，会分两个阶段写入这两份日志文件中，这也是为了保证两份日志之间的一致性，即维护 mysql 的数据一致性。...试想，如果不采用两阶段提交，会发生哪些情况？ 由于 redo log 和 binlog 是两个独立的逻辑，不采用两阶段提交，有两种情况。...两阶段过程异常崩溃处理 如果在两阶段提交的方式下，在 binlog 日志写完，事务在没有 commit 前，即 redo log 日志还没记录 commit 前，mysql 进程发生异常崩溃，MySQL...首先，我们看一下完整的两阶段提交流程，分为准备阶段和提交阶段。 在准备阶段，MySQL 先将数据修改写入 redo log 日志，并将其标记为 prepare 状态，即事务还处于未提交状态。
其实并不能完全解决幻读问题， 这里可以参考另一篇博客[mysql事务隔离级别与加锁分析] SERIALIZABLE隔离级别下，需要分为两种情况讨论： 在系统变量autocommit=0时，也就是禁用自动提交时...`来为记录加锁，分两个情况，比方说： - 如果没有对二级索引进行更新，跟`Select .. for update`一样， 只对聚簇索引 + XLock - 如果对二级索引进行了更新, 不但对聚簇索引...[](/images/mysql/ru_rc_table_scan.png) 2. `SELECT ... FOR UPDATE`进行加锁的情况与上边类似，只不过加的是+ XLock 3....试图 insert， 发现唯一键冲突， 则在唯一索引上加上 S 锁 T3 时刻， SessionA 回滚， 此时 SessionB 和 SessionC 都试图继续执行插入操作， 都要加上 X 锁， 但两个...Session都要等待对方的行锁， 所以出现了死锁 参考资料 [掘金小册-从根上理解MySQL] [公众号:我们都是小青蛙 - MySQL加锁分析三部曲]
场景： 最近，遇到了一个关于mysql 加锁的问题，将当时的情形简化如下，有一个index_test表，表结构如下所示： mysql> CREATE TABLE `index_test` ( `priv_id...不可重复读(Non-repeatable read):当一行数据获取两遍得到不同的结果表示发生了“不可重复读(non-repeatable read) 幻读(Phantom Read):当两个完全相同的查询语句执行得到不同的结果集...然后在网上搜索相关的资料，看看别人有没有遇到过这样的问题，在一篇关于MySQL加锁处理分析的blog中得到了启示，按照blog中组合七：id非唯一索引+RR的理论，gap锁的范围不仅跟被锁定的键有关，还跟主键有关...因此，在我们使用mysql加锁过程中，也首先需要搞清楚，我们的隔离级别是什么，是否开启了binlog等等，然后才能正确分析加锁的范围。...p=771 大神描述Mysql 加锁分析的blog http://hedengcheng.com/?
其实并不能完全解决幻读问题， 这里可以参考另一篇博客[mysql事务隔离级别与加锁分析] SERIALIZABLE隔离级别下，需要分为两种情况讨论： 在系统变量autocommit=0时，也就是禁用自动提交时...，分两个情况，比方说： 如果没有对二级索引进行更新，跟Select .. for update一样， 只对聚簇索引 + XLock 如果对二级索引进行了更新, 不但对聚簇索引 + XLock, 还需要给对应二级索引...next-key Lock，它们对应的聚簇索引记录 + SLock 对最后一个name值为’c曹操’的二级索引记录的下一条二级索引记录加gap锁, 如: 如果命中 miss， 同唯一二级索引一样， 需要在前后两条记录之间...试图 insert， 发现唯一键冲突， 则在唯一索引上加上 S 锁 T3 时刻， SessionA 回滚， 此时 SessionB 和 SessionC 都试图继续执行插入操作， 都要加上 X 锁， 但两个...Session都要等待对方的行锁， 所以出现了死锁 参考资料 [掘金小册-从根上理解MySQL] [公众号:我们都是小青蛙 - MySQL加锁分析三部曲]
什么是两阶段提交 1.1 binlog 与 redolog 1.2 两阶段提交 2. 为什么需要两阶段提交 3. 小结 为什么要两阶段提交？一阶段提交不行吗？...小伙伴们知道，MySQL 中的事务是两阶段提交，我们见到的很多分布式事务也都是两阶段提交的，例如 Seata，那么为什么要两阶段提交呢？一次直接提交了不行吗？今天我们来聊聊这个话题。...什么是两阶段提交 1.1 binlog 与 redolog binlog binlog 我们中文一般称作归档日志，如果大家看过松哥之前发的 MySQL 主从搭建，应该对这个日志有印象，当我们搭建 MySQL...1.2 两阶段提交 在 MySQL 中，两阶段提交的主角就是 binlog 和 redolog，我们来看一个两阶段提交的流程图： 从上图中可以看出，在最后提交事务的时候，有 3 个步骤： 写入 redo...由此可见，两阶段提交能够确保数据的一致性。 3. 小结 好啦，今天和小伙伴们简单聊了一下 MySQL 中的两阶段提交，有问题欢迎留言讨论。
ENGINE=InnoDB; insert into t values(0,0,0),(5,5,5), (10,10,10),(15,15,15),(20,20,20),(25,25,25); MySQL...，next-key lock退化为间隙锁 加锁的基本单位虽然是next-key lock，但是在具体执行的时候，是要分成间隙锁和行锁两段来执行的。...注意我们这里加的是读锁，如果你使用的是for update，MySQL会认为你要更新数据，因此会给主键索引上满足条件的行加上行锁。...，因此不会退化成行锁 继续向右遍历，由于不满足条件4的等值查询，因此在找到id=15这一行以后，会加上next-key lock(10,15] Session A加的锁是(5,10]和(10,15]这两个...这是因为Session A在遍历的时候，从(c=5,id=5)走到(c=10,id=30)这一行以后，满足条件的语句已经有两条，循环就结束了，因此后面的间隙并没有在加锁的范围内，因此Session B的
2PL：Two-Phase Locking 传统RDBMS加锁的一个原则，就是2PL (二阶段锁)：Two-Phase Locking。...相对而言，2PL比较容易理解，说的是锁操作分为两个阶段：加锁阶段与解锁阶段，并且保证加锁阶段与解锁阶段不相交。下面，仍旧以MySQL为例，来简单看看2PL在MySQL中的实现。 ?...从上图可以看出，2PL就是将加锁/解锁分为两个完全不相交的阶段。加锁阶段：只加锁，不放锁。解锁阶段：只放锁，不加锁。...深入理解MySQL如何加锁，有两个比较重要的作用： 可以根据MySQL的加锁规则，写出不会发生死锁的SQL； 可以根据MySQL的加锁规则，定位出线上产生死锁的原因； 下面，来看看两个死锁的例子 (一个是两个...结论：死锁的发生与否，并不在于事务中有多少条SQL语句，死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。
MySQL 版本: 8.0.25 隔离级别: 可重复读 InnoDB有两种不同的SELECT，即普通SELECT 和 锁定读SELECT. 锁定读SELECT 又有两种，即SELECT ......，加锁; FOR SHARE 语法是 MySQL 8.0 时加入的，FOR SHARE 和 LOCK IN SHARE MODE 是等价的，但FOR SHARE 用于替代 LOCK IN SHARE MODE...一致性非锁定读在两种隔离级别RC和RR时，是否有什么不同呢?是的，两种隔离级别下，拍得快照的时间点不同 RC时，同一个事务内的每一个一致性读总是设置和读取它自己的快照。...这两种锁定读在搜索时所遇到的(注意：不是最终结果集中, 但MySQL会对其做一定的优化)每一条索引记录(Index Record)上设置排它锁或共享锁。...且由于MySQL会对锁的粒度做一定优化, 所以应以实际加锁为准. 1.
要回答这两个问题，首先需要了解一些知识。...其中MVCC最大的好处是：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的提高了系统的并发性能，在现阶段，几乎所有的RDBMS，都支持MVCC。...两阶段锁 传统的RDMS加锁的一个原则，就是2PL(Two-Phase Locking，二阶段锁)。也就是说锁操作分为两个阶段：加锁阶段和解锁阶段，并且保证加锁阶段和解锁阶段不想交。...也就是说在一个事务中，不管有多少条增删改，都是在加锁阶段加锁，在 commit 后，进入解锁阶段，才会全部解锁。...对于该组合，MySQL又会进行怎样的加锁呢？看下图： 由于id列上无索引，因此只能走聚簇索引，进行全表扫描。由图可以看出满足条件的记录只有两条，但是，聚簇索引上的记录都会加上X锁。
不过这里有一个小插曲： # 事务T1，REPEATABLE READ隔离级别下 mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> SELECT...我们说语句一和语句二是MySQL中规定的两种锁定读的语法格式，而语句三和语句四由于在执行过程需要首先定位到被改动的记录并给记录加锁，也可以被认为是一种锁定读。...这个UPDATE语句是先对聚簇索引记录进行加锁，后对二级索引记录进行加锁，如果在不同事务中运行上述两个语句，可能发生一种贼奇妙的事情 —— 事务T2持有了聚簇索引记录的锁，事务T1持有了二级索引记录的锁...两个事务都分别持有一个锁，而且都在等待对方已经持有的那个锁，这种情况就是所谓的死锁，两个事务都无法运行下去，必须选择一个进行回滚，对性能影响比较大。 使用SELECT ......; 如果这两个语句采用二级索引来进行锁定读，那么它们的加锁情况和更新带有二级索引列的UPDATE语句一致，就不画图了。
如果不使用"两阶段提交"，那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致：一、先写 redolog 后写 binlog 会丢失数据 1、先写 redolog 后写 binlog。...两阶段提交：1、将新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于"prepare状态"。 然后告知执行器执行完成了，随时可以提交事务。...引擎把刚刚写入的 redo log 改成"提交（commit）状态"，更新完成https://blog.csdn.net/weixin_43189971/article/details/126437659两阶段提交如何保证数据一致性...由此可见，两阶段提交能够确保数据的一致性。...redo_log 采用两阶段提交的方式： redo_log(prepare)：记录新数据，更新redo_log状态为预提交状态。
产生死锁的必要条件 多个并发事务（2个或者以上） 每个事物都持有了锁（或者是已经在等待锁） 每个事务都需要再继续持有锁（为了完成事务逻辑，还必须更新更多的行） 事物之间产生加锁的循环等待，形成死锁...根据主键查找-锁加在主键上 如 begin;select * from tt_copy where id=4 for update; 加锁情况 index PRIMARY of table test.tt_copy...not gap 根据普通索引查找-锁加在普通索引和主键上 如 begin;select * from tt_copy force index(idx_a) where a=4 for update; 加锁情况...+ row based binlog，基本上能够解决所有问题，无需使用Repeatable Read） 适当的 减少Unique 索引，能够减少GAP锁导致的死锁（根据业务情况而定） • 原则之三 在MySQL...，如果死锁中出现Next Key（Gap锁），说明表中一定存在unique索引 多语句事务产生的死锁，确保每条语句操作记录的顺序性，能够极大减少死锁 本文大多数都整理自《死锁-何登成 - 管中窥豹——MySQL
DEFAULT CHARSET=utf8 select * from test where id > 3 and name <'A' for update; 这条SQL语句的将所有id>3的记录进行加锁...，而不是对范围 id>3 and name <'A' 进行加锁，因为name上面没有索引。...如果一个SQL语句无法通过索引进行Locking read，UPDATE，DELETE，那么MySQL将扫描整个表，表中的每一行都将被锁定（在RC级别，通过semi-consistent read，能够提前释放不符合条件的记录...lock tables 是用来加表级锁，它是由MySQL的server层来加这把锁的。...参考资料： http://docs.fordba.com/mysql/refman-5.6-en/innodb-storage-engine.html#innodb-locks-set
你可能注意到了，最后三步看上去有点“绕”，将 redo log 的写入拆成了两个步骤：prepare 和 commit，这就是"两阶段提交"。...Binlog有两种模式，statement 格式的话是记sql语句， row格式会记录行的内容，记两条，更新前和更新后都有。 四、两阶段提交 为什么必须有“两阶段提交”呢？...好了，说完了数据恢复过程，我们回来说说，为什么日志需要“两阶段提交”。这里不妨用反证法来进行解释。...简单说，redo log 和 binlog 都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态保持逻辑上的一致。...这个参数我也建议你设置成 1，这样可以保证 MySQL 异常重启之后 binlog 不丢失。 我还跟你介绍了与 MySQL 日志系统密切相关的“两阶段提交”。
我们常常听到一些关于MySQL的说法，比如“读不加锁”，比如“单表数据要小于1000万”，比如“DDL会锁表”等，比如“单表的索引数量应该小于X个”，如果不加思考和测试就直接全盘接受，就可能犯错误，而DB...第1篇文章首先分析下“读不加锁”这种说法是否正确呢？ 1.Metadata Locking 若考虑元数据锁（metadata lock），读不加锁错误 。...MVCC 在MVCC下读不加锁的说法是有条件的正确。...=test --mysql-user=xxx --mysql-password='xxx' --mysql-host='127.0.0.1' --mysql-port=3306 --max-time=50...总结 MySQL读不加锁是有条件的： 所有读取都会加Metadata Lock MyISAM引擘会加表锁 INNODB引擘读不加锁是利用MVCC实现的 Serializable隔离级别会对所有读取的行加锁
相对而言，2PL比较容易理解，说的是锁操作分为两个阶段：加锁阶段与解锁阶段，并且保证加锁阶段与解锁阶段不相交。下面，仍旧以MySQL为例，来简单看看2PL在MySQL中的实现。...transaction mysql begin; 加锁阶段 insert into 加insert对应的锁 update table 加update对应的锁 delete from 加delete对应的锁...commit 解锁阶段 将insert、update、delete的锁全部解开 上面的例子可以看出2PL就是将加锁、解锁分为两个阶段，并且互相不干扰。...加锁阶段只加锁，解锁阶段只解锁。 7.3 为什么会发生死锁 MyISAM中是不会产生死锁的，因为MyISAM总是一次性获得所需的全部锁，要么全部满足，要么全部等待。...发现没有，跟Session 1的加锁顺序正好相反，如果两个Session恰好都持有了第一把锁，请求加第二把锁，死锁就发生了。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
云直播
实时音视频
