默认情况下，InnoDB工作在可重复读隔离级别下，并且会以Next-Key Lock的方式对数据行进行加锁，这样可以有效防止幻读的发生。Next-Key Lock是行锁和间隙锁的组合，当InnoDB扫描索引记录的时候，会首先对索引记录加上行锁（Record Lock），再对索引记录两边的间隙加上间隙锁（Gap Lock）。加上间隙锁之后，其他事务就不能在这个间隙修改或者插入记录。
数据库本质上是一种共享资源，因此在最大程度提供并发访问性能的同时，仍需要确保每个用户能以一致的方式读取和修改数据。锁机制（Locking）就是解决这类问题的最好武器。
遇到Mysql死锁问题，我们应该怎么排查分析呢？之前线上出现一个insert on duplicate死锁问题，本文将基于这个死锁问题，分享排查分析过程，希望对大家有帮助。
事务:数据库操作的最小工作单元，是作为单个逻辑工作单元执行的一系列操作；事务是一组不可再分割的操作集合（工作逻辑单元）; 典型事务场景(转账)：
先看程序报错： 2017-06-12 21:18:40.856 [ForkJoinPool.commonPool-worker-12] ERROR com.jd.gms.maindata.accurate.service.impl.FixServiceImpl[51] - FixServiceImpl.fixSkuAttribute error java.lang.RuntimeException: org.springframework.dao.DeadlockLoserDataAcces
本文主要是复现场景以及分析具体是哪些锁导致的阻塞，不会重点讲排查思路以及对show engine innodb的内容分析
数据入库这块有离线和实时两套入库系统，写同一个db的同一批mysql表，两边用的都是insert into table on duplicate key update这种方式。实时一直运行，离线5分钟更新一次，当两套系统同时运行时出现了死锁问题，频率还挺高。事务的隔离级别是read committed 读提交。
死锁是并发系统中常见的问题，同样也会出现在数据库MySQL的并发读写请求场景中。当两个及以上的事务，双方都在等待对方释放已经持有的锁或因为加锁顺序不一致造成循环等待锁资源，就会出现“死锁”。常见的报错信息为 Deadlock found when trying to get lock...。
这时候可以用select * from information_schema.innodb_locks;查看锁情况：
提示：公众号展示代码会自动折行，建议横屏阅读 「第一部分 背景」 最近我们发现在Read Committed隔离级别下出现了S类型的Gap锁参与的死锁告警。 本身RC隔离级别上出现Gap锁就很诡异了，更诡异的是两条看起来完全不相干的SQL发生了死锁。让我们一起来分析一下吧。 1.1 事务逻辑 简化来看是一个文件移动功能，目的是将文件从source目录移动到dest目录，逻辑如下： 1）查询 source 的父目录（select lock in share mode） 2）查询 dest 的父目录（selec
MySQL是目前世界上最流行的数据库，InnoDB是MySQL最流行的存储引擎，它在大数据量高并发量的业务场景下，有着非常良好的性能表现，之所以如此，是和InnoDB的锁机制相关。
MySQL中的间隙是指索引中两个索引键之间的空间，间隙锁用于防止范围查询期间的幻读，确保查询结果的一致性和并发安全性。
今天跟大家聊一聊MySQL的事务隔离，并通过一些实验做了些总结。光说不练，假把式，没有经过实践就没有话语权。
这时候可以用 select*frominformation_schema.innodb_locks;查看锁情况：
读者反馈了一个死锁案例，比较有意思，上一篇文章讲了怎么通过调试源码来分析锁，今天再来分析一个死锁场景。
MySQL数据库提供了四种默认的隔离级别，读未提交(read-uncommitted)、读已提交(或不可重复读)(read-committed)、可重复读(repeatable-read)、串行化(serializable)。
锁机制核心功能是用来协调多个会话中多线程并发访问相同资源时，资源的占用问题。锁机制是一个非常大的模块，贯彻MySQL的几大核心难点模块：索引，锁机制，事务。这里是基于MySQL5.6演示的几种典型场景，对面MySQL这几块问题时，有分析流程和思路是比较关键的。在MySQL中常见这些锁概念：共享读锁、排它写锁 ; 表锁、行锁、间隙锁。
此前的文章中，我们介绍了 mysql 中的事务和锁机制。 一文讲透 MySQL 的 MVCC 机制 MySQL 锁机制（上） — 全局锁与表级锁 MySQL 锁机制（下） — 细说 InnoDB 行锁（记录锁、间隙锁与临键锁）
latch与lock latch 可以认为是应用程序中的锁，可以称为闩锁(轻量级的锁) 因为其要求锁定的时间必须要非常短，若持续时间长，则会导致应用性能非常差，在InnoDB存储引擎中，latch又可
锁在现实中的意义为:封闭的器物，以钥匙或暗码开启。在计算机中的锁一般用来管理对共享资源的并发访问，比如我们java同学熟悉的Lock,synchronized等都是我们常见的锁。当然在我们的数据库中也有锁用来控制资源的并发访问，这也是数据库和文件系统的区别之一。
接下来，就跟聊聊上面两个事务执行 SQL 语句的过程中，加了什么锁，从而导致死锁的。
大概几个月之前项目中用到事务，需要保证数据的强一致性，期间也用到了mysql的锁，但当时对mysql的锁机制只是管中窥豹，所以本文打算总结一下mysql的锁机制。
一 前言 工欲善其事必先利其器，前面分析了很多死锁案例，并没有详细的介绍如何通过死锁日志来诊断死锁的成因。本文将介绍如何读懂死锁日志，尽可能的获取信息来辅助我们解决死锁问题。 二 日志分析 2.1 场景 为了更好的学习死锁日志，我们需要提前了解死锁场景 MySQL 5.6 事务隔离级别为RR
A、原子性（Atomicity） 表示组成一个事务的多个数据库操作是一个不可分隔的原子单元，只有所有的操作执行成功，整个事务才提交，事务中任何一个数据库操作失败，已经执行的任何操作都必须撤销，让数据库返回到初始状态。 B、一致性（Consistency） 事务操作成功后，数据库所处的状态和它的业务规则是一致的，即数据不会被破坏。 C、隔离性（Isolation） 在并发数据操作时，不同的事务拥有各自数据空间，它们的操作不会对对方产生干扰。数据库规定了多种事务隔离级别，不同隔离级别对应不同的干扰程度，隔离级别越高，数据一致性越好，但并发性越弱。 D、持久性（Durabiliy） 一旦事务提交成功后，事务中所有的数据操作都必须被持久化到数据库中，即使提交事务后，数据库马上崩溃，在数据库重启时，也必须能保证能够通过某种机制恢复数据。
但是，实际上「插入意向锁」不是意向锁，而是特殊的间隙锁，属于行级锁，注意是「特殊」的间隙锁，并不是我们常说的间隙锁。
提示：公众号展示代码会自动折行，建议横屏阅读 「第一部分 前言」 InnoDB引擎支持行级别锁，实现了四种隔离级别，本文梳理了InnoDB事务系统及锁系统的原理和源码实现，并且对其中一些比较特别的feature做一个简单的介绍。 因为涉及的模块代码非常庞大，部分实现细节并未深入，如有错漏，欢迎指正。 在介绍InnoDB的事务系统和锁系统之前，有必要对一些基本概念做一个简单的回顾。 我们都知道事务的四大属性ACID，这些属性的保证与数据库中的几大模块紧密的耦合在一起： 为了保证原子性Atomicity，数据
一 前言 死锁，其实是一个很有意思也很有挑战的技术问题，大概每个DBA和部分开发同学都会在工作过程中遇见 。关于死锁我会持续写一个系列的案例分析，希望能够对想了解死锁的朋友有所帮助。 二 案例分析 2.1 环境说明 MySQL 5.6 事务隔离级别为RR
以前接触到的数据库死锁，都是批量更新时加锁顺序不一致而导致的死锁，但是上周却遇到了一个很难理解的死锁。借着这个机会又重新学习了一下mysql的死锁知识以及常见的死锁场景。在多方调研以及和同事们的讨论下终于发现了这个死锁问题的成因，收获颇多。虽然是后端程序员，我们不需要像DBA一样深入地去分析与锁相关的源码，但是如果我们能够掌握基本的死锁排查方法，对我们的日常开发还是大有裨益的。
事务 作为单个逻辑工作单元执行的一系列操作。 事务特性 ACID A atomicity 原子性 事务是不可分割的原子单元，要么全部完成，要么全部不完成，不可能停在中间。操作成功 整个事务提交 commit 操作失败 事务回滚 rollback A给B转账 A扣款 B到账 C consistency 一致性 A给B转账 A转了1000 B只到了500 I isolation 隔离性 多个事务并发访问，事务之间是隔离的 D durabiliy 持久性 事务一旦提交，持久化保存在数据库 断电，重启都不会改变数据
一 前言 死锁是每个MySQL DBA 都会遇到的技术问题，本文是自己针对死锁学习的一个总结,了解死锁是什么，MySQL如何检测死锁，处理死锁，死锁的案例，如何避免死锁。
查阅了官方文档，我们可以了解到，插入意向锁（Insert Intention Locks ）其实是一种特殊的gap lock，在行插入前，要获取这个锁（所以这个锁是在行排它锁之前获取）。
在数据库中，除传统的计算资源（如 CPU、RAM、I/O 等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。
之前也列举了几期的MySQL死锁问题，光有操作演练，还缺少一些自己的分析，所以我就打算补充一下。 首先对于死锁问题，我们分析的背景是基于MySQL事务隔离级别为RR,存储引擎为InnoDB,在MySQL 5.6,5.7版本均可复现问题。 怎么来分析一个死锁问题呢，我一直在琢磨这个问题，自己也总结了不少出现的场景，但是感觉还是有一些欠缺或者不完善的地方。那么我们就换一个思路来分析死锁问题，通过日志来反推死锁产生的可能场景，然后依次深入，扩展，这样一来，这个问题的分析就带有通过很多不确定性分析
某天下午组里有一个对外提供创建租户的接口突然产生了MySQL死锁的报警。 该服务是一个老服务，至少有一年没有人改动过该接口，并且租户这个场景只支持创建和查询，其他能力都不支持。收到报警的一刻，内心充满了疑惑："这也能死锁?"
来源：https://www.aneasystone.com/archives/2018/06/insert-locks-via-mysql-source-code.html
事务A执行多次读取操作过程中，由于在事务提交之前，事务B（insert/delete/update）写入了一些符合事务A的查询条件的记录，导致事务A在之后的查询结果与之前的结果不一致，这种情况称之为幻读。
最近在看 小林coding 的文章，看到一篇《字节面试：加了什么锁，导致死锁的？》，自己也跟着做了做，题目如下图：
插入InnoDB自增列，居然是表锁？
在对某个表执行SELECT、INSERT、DELETE、UPDATE语句时，InnoDB存储引擎是不会为这个表添加表级 别的 S锁 或者 X锁 的。在对某个表执行一些诸如 ALTER TABLE 、 DROP TABLE 这类的 DDL 语句时，其 他事务对这个表并发执行诸如SELECT、INSERT、DELETE、UPDATE的语句会发生阻塞。同理，某个事务 中对某个表执行SELECT、INSERT、DELETE、UPDATE语句时，在其他会话中对这个表执行 DDL 语句也会 发生阻塞。这个过程其实是通过在 server层 使用一种称之为 元数据锁 （英文名： Metadata Locks ， 简称 MDL ）结构来实现的。
我们的数据库一般都会并发执行多个事务，多个事务可能会并发的对相同的一批数据进行增删改查操作，可能就会导致我们说的脏写、脏读、不可重复读、幻读这些问题。 这些问题的本质都是数据库的多事务并发问题，为了解决多事务并发问题，数据库设计了事务隔离机制、锁机制、MVCC多版本并发控制隔离机制，用一整套机制来解决多事务并发问题。接下来，我们会深入讲解这些机制，让大家彻底理解数据库内部的执行原理。
一 前言 死锁其实是一个很有意思也很有挑战的技术问题，大概每个DBA和部分开发朋友都会在工作过程中遇见。关于死锁我会持续写一个系列的案例分析，希望能够对想了解死锁的朋友有所帮助。 二 背景知识 2.1 insert 锁机制 在分析死锁案例之前，我们先学习一下背景知识 insert 语句的加锁策略。我们先来看看官方定义:
锁定读的语句加锁类型注意事项select ... for update加X锁务必加上BEGIN， START TRANSACTION或者 SET AUTOCOMMIT=0select ... lock in share mode 加S锁
记录r进行上X锁，先对数据库A、表、页上加意向锁IX，才能对记录r上X锁。
全局锁主要应用于做全库逻辑备份，这样在备份数据库期间，不会因为数据或表结构的更新，而出现备份文件的数据与预期的不一样。
作者：操盛春，爱可生技术专家，公众号『一树一溪』作者，专注于研究 MySQL 和 OceanBase 源码。
当数据库的隔离级别为Repeatable Read或Serializable时,我们来看这样的两个并发事务（场景一）：
大家好，我是架构君，一个会写代码吟诗的架构师。今天说一说mysql的几种锁_初中常见七种沉淀,希望能够帮助大家进步!!!
记录锁也就是仅仅把一条记录锁上，官方的类型名称为： LOCK_REC_NOT_GAP 。比如我们把id值为8的 那条记录加一个记录锁的示意图如图所示。仅仅是锁住了id值为8的记录，对周围的数据没有影响。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
