生活中，最常见的案例之一，十字路口没有红绿灯，到了十字路口相互不让，最后，整个马路瘫痪，在我们技术层面称之为死锁。
MySQL 死锁异常是我们经常会遇到的线上异常类别，一旦线上业务日间复杂，各种业务操作之间往往会产生锁冲突，有些会导致死锁异常。这种死锁异常一般要在特定时间特定数据和特定业务操作才会复现，并且分析解决时还需要了解 MySQL 锁冲突相关知识，所以一般遇到这些偶尔出现的死锁异常，往往一时没有头绪，不好处理。
最近总结了一波死锁问题，和大家分享一下，我这也是从网上各种浏览博客得来，希望原作者见谅，参考博客文末下方。
1. 事务隔离级别问题:当使用READ UNCOMMITTED或READ COMMITTED隔离级别时,脏读或不可重复读会导致死锁。
blog.csdn.net/tr1912/article/details/81668423
所谓死锁：是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用，它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的InnoDB。
死锁是指两个或更多的事务在执行过程中，因争夺资源而造成的一种相互等待的现象。每个事务都持有一个资源并等待获取另一个事务已占有的资源，从而形成了一个循环等待的情况。除非有外部干预，否则这些事务都将无法向前推进。
在 MySQL 运维过程中，锁等待和死锁问题是令各位 DBA 及开发同学非常头痛的事。出现此类问题会造成业务回滚、卡顿等故障，特别是业务繁忙的系统，出现死锁问题后影响会更严重。本篇文章我们一起来学习下什么是锁等待及死锁，出现此类问题又应该如何分析处理呢？
最近项目中突然发现一次锁现象，订单多次付款，最后一次退款。退款完成后支付系统手动第三方回调，支付系统多次通知订单系统，订单系统在这个过程中发生死锁，下面给出订单系统表结构做模拟死锁。
链接: 详解MySQL脏读幻读不可重复读及事务的隔离级别和MVCC、LBCC实现，还有锁的详解 在我们使用锁的时候，有一个问题是需要注意和避免的，我们知道，排它锁有互斥的特性。一个事务或者说一个线程持有锁的时候，会阻止其他的线程获取锁，这个时候会造成阻塞等待，如果循环等待，会有可能造成死锁。
在项目初期，我们是没有将读写表分离的，而是基于一个主库完成读写操作。在业务量逐渐增大的时候，我们偶尔会收到系统的异常报警信息，DBA 通知我们数据库出现了死锁异常。
某天下午组里有一个对外提供创建租户的接口突然产生了MySQL死锁的报警。 该服务是一个老服务，至少有一年没有人改动过该接口，并且租户这个场景只支持创建和查询，其他能力都不支持。收到报警的一刻，内心充满了疑惑："这也能死锁?"
前几天，线上发生了一次数据库死锁问题，这一问题前前后后排查了比较久的时间，这个过程中自己也对数据库的锁机制有了更深的理解。本文总结了这次死锁排查的全过程，并分析了导致死锁的原因及解决方案。希望给大家提供一个死锁的排查及解决思路。
在平常的工作中，更新数据是再正常不过的一个需求了，我们只需要执行一个update语句即可，如果有必要我们还可以加上事务来保证数据的可靠性。
本文是微信公众号【Java技术江湖】的《重新学习MySQL数据库》其中一篇，本文部分内容来源于网络，为了把本文主题讲得清晰透彻，也整合了很多我认为不错的技术博客内容，引用其中了一些比较好的博客文章，如有侵权，请联系作者。
但事实上，Innodb 引擎实现了行级锁，与只支持表级锁的 MyISAM 相比，这显然能够有效减少锁冲突，这也是 Innodb 最终能够战胜 MyISAM 成为 MySQL 默认存储引擎的一个重要原因。 因此我们在使用中，最为频繁接触到就是行级锁，用好行级锁，减少锁冲突，将有效提升 MySQL 的执行性能，本文我们就来详细介绍一下 Innodb 中的各种行级锁。
此前的文章中，我们介绍了 mysql 中的事务和锁机制。 一文讲透 MySQL 的 MVCC 机制 MySQL 锁机制（上） — 全局锁与表级锁 MySQL 锁机制（下） — 细说 InnoDB 行锁（记录锁、间隙锁与临键锁）
死锁是指由于每个事务都持有对方需要的锁而无法进行其他事务的情况，形成一个循环的依赖关系。因为这两个事务都在等待资源变得可用，所以两个都不会释放它持有的锁。
MyISAM表的读和写是串行的，但这是就总体而言的。在一定条件下，MyISAM表也支持查询和插入操作的并发进行。
最近读了一篇关于MYSQL的文章，主要是更深入化的讲解MYSQL的锁机制，写的真是好。但里面细细的读，发现一个问题，索引的问题，一般我们都人为索引是我们查询中的救星，他可以帮助我们摆脱，全表扫描，加快查询的速度，让查询更快减少系统性能上的瓶颈。
三分钟了解Mysql的表级锁 一分钟深入Mysql的意向锁 mysql锁相关讲解及其应用——《深究mysql锁》
对于行级锁与表级锁的折中，开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般
2、外部锁的死锁检测：InnoDB不能完全自动检测死锁，则需要设置锁等待超时参数innodb_lock_wait_timeout来解决。
1、尽量不要主动使用Lock table之类的语句，使用事务去代替此来操作。之前有过开发同学想向DBA申请lock table权限，这个行为本身是不妥当的。
笔者负责的一个系统最近有新功能上线后突然在预警模块不定时报出MySQL死锁导致事务回滚。幸亏，上游系统采用了异步推送和同步查询结合的方式，感知到推送失败及时进行了补偿。于是，笔者争取了一点时间详细分析了导致死锁的多个事务的执行时序，分析并且得出解决方案。
数据库锁定机制简单来说，就是数据库为了保证数据的一致性，而使各种共享资源在被并发访问变得有序所设计的一种规则。对于任何一种数据库来说都需要有相应的锁定机制，所以MySQL自然也不能例外。MySQL数据库由于其自身架构的特点，存在多种数据存储引擎，每种存储引擎所针对的应用场景特点都不太一样，为了满足各自特定应用场景的需求，每种存储引擎的锁定机制都是为各自所面对的特定场景而优化设计，所以各存储引擎的锁定机制也有较大区别。MySQL各存储引擎使用了三种类型（级别）的锁定机制：表级锁定，行级锁定和页级锁定。 1.表级锁定（table-level）
转载自http://www.cnblogs.com/luyucheng/p/6297752.html
死锁发生在一个事务中，事务对多个表进行了操作。在报错日志中，死锁发生在tableA与tableB。一开始怀疑此次发布的某个改动中对上面这两张表新增了select或update操作。将注意力用在排查这个问题上。排查后发现没有相关的变更，又猜测是否是由于更改造成并发请求进来，接口原来是有加分布式锁的，需求更改中缩小了分布式锁的粒度，确实是有可能造成并发请求。但很快又否定了，秒杀场景下的并发量尚且不会发生死锁，何况是这个接口？觉得问题应该别有所在。先回滚了需求后，联系dba执行了命令SHOW ENGINE INNODB STATUS将死锁日志拉取了出来：
索引是一种特殊的文件,它们包含着对数据表里所有记录的引用指针，相当于书本的目录。其作用就是加快数据的检索效率。常见索引类型有主键、唯一索引、复合索引、全文索引。
锁是计算机协调多个进程或线程并发访问某一资源的机制。锁保证数据并发访问的一致性、有效性；锁冲突也是影响数据库并发访问性能的一个重要因素。锁是Mysql在服务器层和存储引擎层的的并发控制。
在高并发的数据库应用中，由于多个事务同时操作相同的资源，可能会导致死锁的出现。MySQL作为一种常用的关系型数据库，提供了死锁检测和日志记录的功能。本文将介绍如何通过分析MySQL的死锁日志，并使用Java代码来解决死锁的问题。阅读本文后，读者将能够了解如何定位和解决MySQL数据库中的死锁问题，并加深对MySQL和Java的理解。
Java 语言通过 synchronized 关键字来保证原子性，这是因为每一个 Object 都有一个隐含的锁，这个也称作监视器对象。在进入 synchronized 之前自动获取此内部锁，而一旦离开此方式，无论是完成或者中断都会自动释放锁。显然这是一个独占锁，每个锁请求之间是互斥的。相对于众多高级锁 (Lock/ReadWriteLock 等)，synchronized 的代价都比后者要高。但是 synchronzied 的语法比较简单，而且也比较容易使用和理解。Lock 一旦调用了 lock() 方法获取到锁而未正确释放的话很有可能造成死锁，所以 Lock 的释放操作总是跟在 finally 代码块里面，这在代码结构上也是一次调整和冗余。Lock 的实现已经将硬件资源用到了极致，所以未来可优化的空间不大，除非硬件有了更高的性能，但是 synchronized 只是规范的一种实现，这在不同的平台不同的硬件还有很高的提升空间，未来 Java 锁上的优化也会主要在这上面。既然 synchronzied 都不可能避免死锁产生，那么死锁情况会是经常容易出现的错误，下面具体描述死锁发生的原因及解决方法。
即，死锁问题具有业务关联、机制复杂、类型多样等特点，导致当数据库发生死锁问题时，不是那么容易分析。
本文针对上一篇《MySQL优化案例分享》文章中提到的线上业务产生的一个死锁问题进行展开讨论，主要针对两个update操作导致的死锁的场景，借此机会正好总结下MySQL锁及分析下产生死锁的原因和解决方案；
锁作为 MySQL 知识体系的主要部分之一，是每个 DBA 都需要学习和掌握的知识。锁保证了数据库在并发的场景下数据的一致性，同时锁冲突也是影响数据库性能的因素之一。而锁冲突中，有一类很经典的场景经常会拿出来讨论：死锁。最近刚好也遇到了一个典型的死锁案例，本文会基于这个案例，做一次详细的分析与拆解。
当数据库中有多个操作需要修改同一数据时，不可避免的会产生数据的脏读。这时就需要数据库具有良好的并发控制能力，这一切在MySQL中都是由服务器和存储引擎来实现的。
关于互联网常见层次架构，由于小编还没整理完毕(预计周四推送)，先来一篇数据库的干货，来满足下大家的胃口，关于mysql的行级锁、表级锁、页级锁的分析，这个在行业应用中设计数据库非常常见的场景。 1常见锁有哪些 在计算机科学中，锁是在执行多线程时用于强行限制资源访问的同步机制，即用于在并发控制中保证对互斥要求的满足。 在 DBMS 中，可以按照锁的粒度把数据库锁分为行级锁(INNODB 引擎)、表级锁(MYISAM 引擎)和页级锁(BDB 引擎 )。 行级锁 行级锁是 Mysql 中锁定粒度最细的一种锁，表
开始今天的文章之前，先说明下昨天文章中的一个错误，昨天文章最后说replace into带来的死锁问题可以使用insert into duplicate key update的方法来解决，今天实际测试的时候，还是遇到了一些问题，改方法并没有完全解决死锁的问题，来看测试的结果。
死锁是指两个或两个以上的线程在执行过程中，因争夺资源而造成的一种互相等待的现象。若无外力作用，它们都将无法推进下去。
行级锁是Mysql中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小，但加锁的开销也最大。有可能会出现死锁的情况。 行级锁按照使用方式分为共享锁和排他锁。
InnoDB 行锁是通过对索引数据页上的记录（record）加锁实现的。主要实现算法有 3 种：Record Lock、Gap Lock 和 Next-key Lock。
派大星：MySQL是通过MVCC机制来实现的，就是多版本并发控制，multi-version concurrency control。innodb存储引擎，会在每行数据的最后加两个隐藏列，一个保存行的创建事件，一个保存行的删除事件，但是这儿存放的不是时间，而是事务id，事务id是mysql自己维护的自增的，全局唯一。事务id，在mysql内部是全局唯一递增的，事务id=1，事务id=2，事务id=3 在一个事务内查询的时候，mysql只会查询创建时间的事务id小于等于当前事务id的行，这样可以确保这个行是在当前事务中创建，或者是之前创建的；同时一个行的删除时间的事务id要么没有定义（就是没删除），要么是比当前事务id大（在事务开启之后才被删除）；满足这两个条件的数据都会被查出来。
很早之前我写过几篇关于MySQL死锁的分析，比如 换个角度看待MySQL死锁的一点简单认识 MySQL死锁的两个小案例 MySQL在RR隔离级别下的unique失效和死锁模拟 两个死锁的实例 (r5笔记第90天) 这样分析一个死锁问题 但是感觉不过瘾，而且分析的都是一些特定的场景，好像还缺少一些举一反三的感觉，所以今天就补上这一波。 MySQL里的锁兼容列表大体是这样的关系，如果第一次看会有些晕，感觉抓不住重点，其实有一点小技巧。 首先InnoDB实现了两种类似的行锁，即S(共享锁）和X(排他锁），而Inn
当数据库的隔离级别为Repeatable Read或Serializable时,我们来看这样的两个并发事务（场景一）：
总的来说，MySQL各存储引擎使用了三种类型（级别）的锁定机制：行级锁定，页级锁定和表级锁定。下面我们先分析一下MySQL这三种锁定的特点和各自的优劣所在。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
