在 MySQL 运维过程中，锁等待和死锁问题是令各位 DBA 及开发同学非常头痛的事。出现此类问题会造成业务回滚、卡顿等故障，特别是业务繁忙的系统，出现死锁问题后影响会更严重。本篇文章我们一起来学习下什么是锁等待及死锁，出现此类问题又应该如何分析处理呢？
上述这个错误，接触 MySQL 的同学或多或少应该都遇到过，专业一点来说，这个报错我们称之为锁等待超时。
死锁是指由于每个事务都持有对方需要的锁而无法进行其他事务的情况，形成一个循环的依赖关系。因为这两个事务都在等待资源变得可用，所以两个都不会释放它持有的锁。
重点关注 ： Innodb_row_lock_time_avg 、Innodb_row_lock_waits 、Innodb_row_lock_time
在多用户并发访问数据库时，为了保证数据的一致性和完整性，必须使用锁机制来控制对共享资源的访问。MySQL数据库也不例外，它提供了多种锁机制来保证数据的正确性和可靠性。本文将详细介绍MySQL的锁机制，包括锁分类、锁级别、锁粒度、锁冲突等方面。
在MySQL中，读操作可以分成两类：快照读 (snapshot read)与当前读 (current read)。快照读，读取的是记录的可见版本 (有可能是历史版本)，不用加锁。当前读，读取的是记录的最新版本，并且，当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录。
MySQL 5.7增强了半同步复制，rpl_semi_sync_master_wait_point增加了AFTER_SYNC的值，由该参数AFTER_SYNC/AFTER_COMMIT两个值选择是否启用增强半同步。
接口响应时间超长，耗时几十秒才返回错误提示，后台日志中出现Lock wait timeout exceeded; try restarting transaction的错误
对于数据库系统来说在多用户并发条件下提高并发性的同时又要保证数据的一致性一直是数据库系统追求的目标，既要满足大量并发访问的需求又必须保证在此条件下数据的安全，为了满足这一目标大多数数据库通过锁和事务机制来实现，MySQL数据库也不例外。尽管如此我们仍然会在业务开发过程中遇到各种各样的疑难问题，本文将以案例的方式演示常见的并发问题并分析解决思路。
接下来，就跟聊聊上面两个事务执行 SQL 语句的过程中，加了什么锁，从而导致死锁的。
随着MYSQL 8 越来越成熟，未来MYSQL 将会开始替换 MYSQL 5.7X成为新的MYSQL 数据库在市面上的主力。
所有session可以读；但是当前session 更新插入报错，其他session 更新插入等待。 比如： 在数据迁移时，加读锁，防止任何session的更新操作。
这篇博文源于公司一个批处理的项目异常而起的。先简单描述下发生背景。一个基于spring batch开发的批处理应用，线上运行了9个多月后，某一天突然跑批任务失败了，检查日志得知，是因为一个mysql异常导致的：Lock wait timeout exceeded。msyql事务锁等待超时这个异常虽然不常见，但随便一搜就会看到大量的相关的信息。导致这个异常的原因就是mysql数据库事务锁等待超时，默认超时时间是50S。但我们的批处理业务从逻辑上讲不会出现这种事务排他锁等待的情况，不得其解。故通过以下这些实例来捋一捋mysql事务内隔离级别和锁等知识点，看看是否如我们了解的这样，同时加深下印象。
一 前言 死锁是每个MySQL DBA 都会遇到的技术问题，本文是自己针对死锁学习的一个总结,了解死锁是什么，MySQL如何检测死锁，处理死锁，死锁的案例，如何避免死锁。
转载：https://www.cnblogs.com/zero-gg/p/9057092.html
如果有一天业务系统需要增大一个字段长度，能否在线上直接修改呢？在回答这个问题前，我们先来看一个案例：
对于MGR这样的"分布式"系统而言，需要在多个节点间保障事务的一致性，无论各个节点状态正常，或者个别节点处于故障修复状态，都要能保证各个节点的事务数据最终一致。所谓的最终一致性是指当所有写事务请求都停止后，各个节点上的事务数据是一致的。
出现这个问题感觉还是挺疑惑的，因为测试环境已经稳定运行了几个月的时间，一直没有出现过mysql事务锁的问题，于是开始着手查问题。
本文是微信公众号【Java技术江湖】的《重新学习MySQL数据库》其中一篇，本文部分内容来源于网络，为了把本文主题讲得清晰透彻，也整合了很多我认为不错的技术博客内容，引用其中了一些比较好的博客文章，如有侵权，请联系作者。
在事务1执行INSERT INTO user VALUES(null, 'tenmao', 3);失败后，执行事务2，事务2等待后，再继续执行事务1，触发死锁。
行锁变表锁，是福还是坑？如果你不清楚MySQL加锁的原理，你会被它整的很惨！不知坑在何方？没事，我来给你们标记几个坑。遇到了可别乱踩。通过本章内容，带你学习MySQL的行锁，表锁，两种锁的优缺点，行锁变表锁的原因，以及开发中需要注意的事项。还在等啥？经验等你来拿！
行级锁是Mysql中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小，但加锁的开销也最大。有可能会出现死锁的情况。 行级锁按照使用方式分为共享锁和排他锁。
需要注意的是，故障恢复的具体步骤和策略会根据故障的类型和严重程度而有所不同。此外，MySQL的不同版本可能还会有不同的故障恢复机制。
前段时间做了很多慢SQL的优化工作，这周刚好又被反馈服务出现了死锁导致了业务报错。看了一下云数据库的告警日志，发现出现了比较多的事务未提交、死锁、等待行锁的严重警告。都是一些棘手的运维工作，涉及到业务流程的梳理、SQL的优化等工作。
Mysql错误: ERROR 1205: Lock wait timeout exceeded解决办法【四星】❤❤❤❤【临时解决方案】
组复制可以以单主模式或多主模式运行，缺省采用单主模式。单主模式中只有一个可以读写的服务器，其它服务器只读。多主模式中，所有服务器均可读写。无论部署模式如何，组复制都不处理客户端故障转移，而必须由应用程序本身、连接器或中间件（如MySQL router）处理此问题。
在上文我们曾小小的提到过，在索引失效的情况下，MySQL会把所有聚集索引记录和间隙都锁上，我们称之为锁表，或叫行锁升表锁.
数据库锁定机制简单来说，就是数据库为了保证数据的一致性，而使各种共享资源在被并发访问变得有序所设计的一种规则。对于任何一种数据库来说都需要有相应的锁定机制，所以MySQL自然也不能例外。MySQL数据库由于其自身架构的特点，存在多种数据存储引擎，每种存储引擎所针对的应用场景特点都不太一样，为了满足各自特定应用场景的需求，每种存储引擎的锁定机制都是为各自所面对的特定场景而优化设计，所以各存储引擎的锁定机制也有较大区别。MySQL各存储引擎使用了三种类型（级别）的锁定机制：表级锁定，行级锁定和页级锁定。 1.表级锁定（table-level）
全局锁就是对整个数据库实例加锁。MySQL提供了一个加全局读锁的方法，命令是 Flush tables with read lock (FTWRL)。
MySQL数据库提供了四种默认的隔离级别，读未提交(read-uncommitted)、读已提交(或不可重复读)(read-committed)、可重复读(repeatable-read)、串行化(serializable)。
现在的服务都是分布式，MySQL的集群架构也是一样。那么MySQL的集群架构中有一个点是读写分离，而读写分离是基于binlog实现的。那么接下来就MySQL的读写分离和binlog为突破点进行分析为什么大厂中的默认隔离级别是RC。总体来说以时间线为基准进行讲解。
PG对于事务行为有更为苛刻的保证，使用回滚的方式避免幻读，MYSQL不会回滚事务所以在业务侧看起来更加易用但也更加容易让人混淆。
在之前的文章中，我对MySQL并行复制做过一个简单的介绍，有兴趣可以翻看5月19日的文章《MySQL并行复制解析》。今天针对这个问题，补充一些知识点。
解决脏读 修改时加排他锁(写锁)，直到事务提交后才释放，读取时加共享锁(读锁)，其他事务只能读取，不能再有更新操作 ，防止脏读
遇到Mysql死锁问题，我们应该怎么排查分析呢？之前线上出现一个insert on duplicate死锁问题，本文将基于这个死锁问题，分享排查分析过程，希望对大家有帮助。
小胖真的让人不省心。继上次小胖误删数据之后，这次这货直接给我把整个表锁住了。页面无响应，用户疯狂投诉，我特么脸都绿了。。。
在项目初期，我们是没有将读写表分离的，而是基于一个主库完成读写操作。在业务量逐渐增大的时候，我们偶尔会收到系统的异常报警信息，DBA 通知我们数据库出现了死锁异常。
我们在运维MySQL的过程中，肯定多多少少遇到过Innodb row lock的问题，如果在线上遇到我们可能会看到一大片的session处于堵塞状态通常我们在show processlist中会看到如下：
我们都是知道，数据库中锁的设计是解决多用户同时访问共享资源时的并发问题。在访问共享资源时，锁定义了用户访问的规则。根据加锁的范围，MySQL 中的锁可大致分成全局锁，表级锁和行锁三类。在本篇文章中，会依次介绍三种类型的锁。在阅读本篇文章后，应该掌握如下的内容：
InnoDB存储引擎支持行级锁 其大类可以细分为共享锁和排它锁两类 共享锁(S)：允许拥有共享锁的事务读取该行数据。当一个事务拥有一行的共享锁时，另外的事务可以在同一行数据也获得共享锁，但另外的事务无法获得同一行数据上的排他锁
作为一个后端工程师，想必没有人没用过数据库，跟我一起复习一下MySQL吧，本文是我学习《MySQL实战45讲》的总结笔记的第四篇，总结了MySQL的锁相关知识。
初次接触二阶段提交，源于想以事务的方式实现对 MongoDB 中多个集合数据的修改，而 MongoDB 本身不支持事务，官方推荐的方案就是使用二阶段提交。
此前的文章中，我们介绍了 mysql 中的事务和锁机制。 一文讲透 MySQL 的 MVCC 机制 MySQL 锁机制（上） — 全局锁与表级锁 MySQL 锁机制（下） — 细说 InnoDB 行锁（记录锁、间隙锁与临键锁）
MySQL调优对于很多程序员而言，都是一个非常棘手的问题，多数情况都是因为对数据库出现问题的情况和处理思路不清晰。在进行MySQL的优化之前必须要了解的就是MySQL的查询过程，很多的查询优化工作实际上就是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行而已。 就在昨天我在百忙之中抽出空余时间面试了个腾讯30k出来的，我开口就是：MYSQL性能调优如何入手？他的回答的：基础优化、优化的哲学、优化需求、优化的思路、存储引擎层、数据库优化、等等细节，好吧我承认我败了。 但是我严重怀疑他是做了准备而来的，不然没有什么人可以记得这么清楚有条理，果不其然，在他入职之后说出了实情；
死锁是指两个或更多的事务在执行过程中，因争夺资源而造成的一种相互等待的现象。每个事务都持有一个资源并等待获取另一个事务已占有的资源，从而形成了一个循环等待的情况。除非有外部干预，否则这些事务都将无法向前推进。
这个问题我相信大家对它并不陌生，但是有很多人对它产生的原因以及处理吃的不是特别透，很多情况都是交给DBA去定位和处理问题，接下来我们就针对这个问题来展开讨论。
因为数据也是一种供许多用户共享的资源，如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素，所以进一步学习MySQL，就需要去了解它的锁机制。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
