当你开始执行一个 ALTER ，而你遇到了可怕的“元数据锁定等待”，我敢肯定你一定遇见过。我最近遇到了一个案例，其中被更改的表要执行一个很小范围的更新（100行）。ALTER 在负载测试期间一直等待了几个小时。在停止负载测试后，ALTER 按预期在不到一秒的时间内就完成了。那么这里发生了什么？
创新互联建站是一家专注于网站设计、网站建设与策划设计,汉中网站建设哪家好?创新互联建站做网站,专注于网站建设十载,网设计领域的专业建站公司;建站业务涵盖:汉中等地区。汉中做网站价格咨询:18982081108
检查外键
每当有奇数次锁定时，我的第一直觉就是检查外键。当然这张表有一些外键引用了一个更繁忙的表。但是这种行为似乎仍然很奇怪。对表运行 ALTER 时，会针对子表请求一个 SHARED_UPGRADEABLE 元数据锁。还有针对父级的 SHARED_READ_ONLY 元数据锁。
我们来看看如何根据文档获取元数据锁定[1]：
如果给定锁定有多个服务器，则首先满足最高优先级锁定请求，并且与 max_write_lock_count系统变量有关。写锁定请求的优先级高于读取锁定请求。
[1]：
请务必注意锁定顺序是序列化的：语句逐个获取元数据锁，而不是同时获取，并在此过程中执行死锁检测。
通常在考虑队列时考虑先进先出。如果我发出以下三个语句（按此顺序），它们将按以下顺序完成：
1. INSERT INTO parent2. ALTER TABLE child3. INSERT INTO parent
但是当子 ALTER 语句请求对父进行读取锁定时，尽管排序，但两个插入将在 ALTER 之前完成。以下是可以演示此示例的示例场景：
数据初始化：
CREATE TABLE `parent` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`val` varchar(10) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;
CREATE TABLE `child` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`parent_id` int(11) DEFAULT NULL,
`val` varchar(10) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idx_parent` (`parent_id`),
CONSTRAINT `fk_parent` FOREIGN KEY (`parent_id`) REFERENCES `parent` (`id`) ON DELETE CASCADE ON UPDATE NO ACTION
) ENGINE=InnoDB;
INSERT INTO `parent` VALUES (1, "one"), (2, "two"), (3, "three"), (4, "four");
Session 1:
start transaction;update parent set val = "four-new" where id = 4;
Session 2:
alter table child add index `idx_new` (val);
Session 3:
start transaction;update parent set val = "three-new" where id = 3;
此时，会话 1 具有打开的事务，并且处于休眠状态，并在父级上授予写入元数据锁定。 会话 2 具有在子级上授予的可升级（写入）锁定，并且正在等待父级的读取锁定。最后会话 3 具有针对父级的授权写入锁定：
mysql select * from performance_schema.metadata_locks;+-------------+-------------+-------------------+---------------+-------------+| OBJECT_TYPE | OBJECT_NAME | LOCK_TYPE | LOCK_DURATION | LOCK_STATUS |+-------------+-------------+-------------------+---------------+-------------+| TABLE | child | SHARED_UPGRADABLE | TRANSACTION | GRANTED | - ALTER (S2)| TABLE | parent | SHARED_WRITE | TRANSACTION | GRANTED | - UPDATE (S1)| TABLE | parent | SHARED_WRITE | TRANSACTION | GRANTED | - UPDATE (S3)| TABLE | parent | SHARED_READ_ONLY | STATEMENT | PENDING | - ALTER (S2)+-------------+-------------+-------------------+---------------+-------------+
请注意，具有挂起锁定状态的唯一会话是会话 2（ALTER）。会话 1 和会话 3 （分别在 ALTER 之前和之后发布）都被授予了写锁。排序失败的地方是在会话 1 上发生提交的时候。在考虑有序队列时，人们会期望会话 2 获得锁定，事情就会继续进行。但是，由于元数据锁定系统的优先级性质，会话 3 具有锁定，会话 2 仍然等待。
如果另一个写入会话进入并启动新事务并获取针对父表的写锁定，则即使会话 3 完成，ALTER 仍将被阻止。
只要我保持一个对父表打开元数据锁定的活动事务，子表上的 ALTER 将永远不会完成。更糟糕的是，由于子表上的写锁定成功（但是完整语句正在等待获取父读锁定），所以针对子表的所有传入读取请求都将被阻止！
另外，请考虑一下您通常如何对无法完成的语句进行故障排除。您查看已经打开较长时间的事务（在进程列表和 InnoDB 状态中）。但由于阻塞线程现在比 ALTER 线程更年轻，因此您将看到的最旧的事务/线程是 ALTER 。
这正是这种情况下发生的情况。在准备发布时，我们的客户端正在运行 ALTER 语句并结合负载测试（一种非常好的做法！）以确保顺利发布。问题是负载测试保持对父表打开一个活动的写事务。这并不是说它只是一直在写，而是有多个线程，一个总是活跃的。 这阻止了 ALTER 完成并阻止对相对静态的子表的随后的读请求。
幸运的是，这个问题有一个解决方案（除了从设计模式中驱逐外键）。变量 max_write_lock_count[2] 可用于允许在写入锁定之后在读取锁定之前授予读取锁定连续写锁。默认情况下，此变量设置为 18446744073709551615，如果你对该表发出 10,000 次写入/秒，那么你的读将被锁定 5800 万年……
在程序员的职业生涯中，总会遇到数据库表被锁的情况，前些天就又撞见一次。由于业务突发需求，各个部门都在批量操作、导出数据，而数据库又未做读写分离，结果就是：数据库的某张表被锁了！
用户反馈系统部分功能无法使用，紧急排查，定位是数据库表被锁，然后进行紧急处理。这篇文章给大家讲讲遇到类似紧急状况的排查及解决过程，建议点赞收藏，以备不时之需。
用户反馈某功能页面报502错误，于是第一时间看服务是否正常，数据库是否正常。在控制台看到数据库CPU飙升，堆积大量未提交事务，部分事务已经阻塞了很长时间，基本定位是数据库层出现问题了。
查看阻塞事务列表，发现其中有锁表现象，本想利用控制台直接结束掉阻塞的事务，但控制台账号权限有限，于是通过客户端登录对应账号将锁表事务kill掉，才避免了情况恶化。
下面就聊聊，如果当突然面对类似的情况，我们该如何紧急响应？
想象一个场景，当然也是软件工程师职业生涯中会遇到的一种场景：原本运行正常的程序，某一天突然数据库的表被锁了，业务无法正常运转，那么我们该如何快速定位是哪个事务锁了表，如何结束对应的事物？
首先最简单粗暴的方式就是：重启MySQL。对的，网管解决问题的神器——“重启”。至于后果如何，你能不能跑了，要你自己三思而后行了！
重启是可以解决表被锁的问题的，但针对线上业务很显然不太具有可行性。
下面来看看不用跑路的解决方案：
遇到数据库阻塞问题，首先要查询一下表是否在使用。
如果查询结果为空，那么说明表没在使用，说明不是锁表的问题。
如果查询结果不为空，比如出现如下结果：
则说明表（test）正在被使用，此时需要进一步排查。
查看数据库当前的进程，看看是否有慢SQL或被阻塞的线程。
执行命令：
该命令只显示当前用户正在运行的线程，当然，如果是root用户是能看到所有的。
在上述实践中，阿里云控制台之所以能够查看到所有的线程，猜测应该使用的就是root用户，而笔者去kill的时候，无法kill掉，是因为登录的用户非root的数据库账号，无法操作另外一个用户的线程。
如果情况紧急，此步骤可以跳过，主要用来查看核对：
如果情况紧急，此步骤可以跳过，主要用来查看核对：
看事务表INNODB_TRX中是否有正在锁定的事务线程，看看ID是否在show processlist的sleep线程中。如果在，说明这个sleep的线程事务一直没有commit或者rollback，而是卡住了，需要手动kill掉。
搜索的结果中，如果在事务表发现了很多任务，最好都kill掉。
执行kill命令：
对应的线程都执行完kill命令之后，后续事务便可正常处理。
针对紧急情况，通常也会直接操作第一、第二、第六步。
这里再补充一些MySQL锁相关的知识点：数据库锁设计的初衷是处理并发问题，作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地控制资源的访问规则，而锁就是用来实现这些访问规则的重要数据结构。
根据加锁的范围，MySQL里面的锁大致可以分成全局锁、表级锁和行锁三类。MySQL中表级别的锁有两种：一种是表锁，一种是元数据锁（metadata lock，MDL)。
表锁是在Server层实现的，ALTER TABLE之类的语句会使用表锁，忽略存储引擎的锁机制。表锁通过lock tables… read/write来实现，而对于InnoDB来说，一般会采用行级锁。毕竟锁住整张表影响范围太大了。
另外一个表级锁是MDL（metadata lock），用于并发情况下维护数据的一致性，保证读写的正确性，不需要显式的使用，在访问一张表时会被自动加上。
常见的一种锁表场景就是有事务操作处于：Waiting for table metadata lock状态。
MySQL在进行alter table等DDL操作时，有时会出现Waiting for table metadata lock的等待场景。
一旦alter table TableA的操作停滞在Waiting for table metadata lock状态，后续对该表的任何操作（包括读）都无法进行，因为它们也会在Opening tables的阶段进入到Waiting for table metadata lock的锁等待队列。如果核心表出现了锁等待队列，就会造成灾难性的后果。
通过show processlist可以看到表上有正在进行的操作（包括读），此时alter table语句无法获取到metadata 独占锁，会进行等待。
通过show processlist看不到表上有任何操作，但实际上存在有未提交的事务，可以在information_schema.innodb_trx中查看到。在事务没有完成之前，表上的锁不会释放，alter table同样获取不到metadata的独占锁。
处理方法：通过 select * from information_schema.innodb_trxG, 找到未提交事物的sid，然后kill掉，让其回滚。
通过show processlist看不到表上有任何操作，在information_schema.innodb_trx中也没有任何进行中的事务。很可能是因为在一个显式的事务中，对表进行了一个失败的操作（比如查询了一个不存在的字段），这时事务没有开始，但是失败语句获取到的锁依然有效，没有释放。从performance_schema.events_statements_current表中可以查到失败的语句。
处理方法：通过performance_schema.events_statements_current找到其sid，kill 掉该session，也可以kill掉DDL所在的session。
总之，alter table的语句是很危险的（核心是未提交事务或者长事务导致的），在操作之前要确认对要操作的表没有任何进行中的操作、没有未提交事务、也没有显式事务中的报错语句。
如果有alter table的维护任务，在无人监管的时候运行，最好通过lock_wait_timeout设置好超时时间，避免长时间的metedata锁等待。
关于MySQL的锁表其实还有很多其他场景，我们在实践的过程中尽量避免锁表情况的发生，当然这需要一定经验的支撑。但更重要的是，如果发现锁表我们要能够快速的响应，快速的解决问题，避免影响正常业务，避免情况进一步恶化。所以，本文中的解决思路大家一定要收藏或记忆一下，做到有备无患，避免突然状况下抓瞎。
锁是需要事务结束后才释放的。
一个是 MVCC，一个是两阶段锁协议。
为什么要并发控制呢？是因为多个用户同时操作 MySQL 的时候，为了提高并发性能并且要求如同多个用户的请求过来之后如同串行执行的一样（为了解决脏读、不可重复读、幻读）
官方定义：
两阶段锁协议是指所有事务必须分两个阶段对数据加锁和解锁，在对任何数据进行读、写操作之前，事务首先要获得对该数据的封锁；在释放一个封锁之后，事务不再申请和获得任何其他封锁。
对应到 MySQL 上分为两个阶段：
但是两阶段锁协议不要求事务必须一次将所有需要使用的数据加锁（innodb在需要的索引列数据才锁行），并且在加锁阶段没有顺序要求，所以这种并发控制方式会形成死锁。
MySQL有两种死锁处理方式：
死锁检测 （默认开启）
死锁检测的原理是构建一个以事务为顶点、锁为边的有向图，判断有向图是否存在环，存在即有死锁。
回滚
检测到死锁之后，选择插入更新或者删除的行数最少的事务回滚，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段来判断。
收集死锁信息：
减少死锁：
死锁解决：
问题：Lock wait timeout exceeded; try restarting transaction
MySQL版本：5.6.44
官方文档
意思是：InnoDB在锁等待超时过期时报告此错误。等待时间过长的语句被回滚（而不是整个事务）。如果SQL语句需要等待其他事务完成的时间更长，则可以增加 innodb_lock_wait_timeout 配置选项的值；如果太多长时间运行的事务导致锁定问题并降低繁忙系统上的并发性，则可以减少该选项的值。
锁等待超时，可能是出现了死锁，也可能有事务长时间未提交
库：information_schema
表：
查看各表信息
innodb_trx 表
innodb_locks 表
innodb_lock_waits 表
processlist 表
模拟出现死锁
准备一张只有主键的表：t_test (id)
Navicat 新建查询1
Navicat 新建查询2
检查是否锁表
查询当前正在执行的事务
查询当前出现的锁
查询锁等待对应的关系
查询等待锁的事务所执行的SQL
最后，事务2 等待锁超时报错： Lock wait timeout exceeded; try restarting transaction;
通过事务线程ID查找进程信息
win10 查看端口信息
最近接了一个锅,进入新公司接手了一个进入交付阶段的项目.在code review的时候发现很多问题,然后开始修复bug.
在测试阶段突然发现几乎所有涉及到更新的操作都失败,下面贴出异常信息.
第一次 出现的时候百度了一下,猜想可能是多服务部署资源冲突,重启服务故障消失.所以没有特别重视
第二次 出现的时候只有测试环境部署,不存在多机资源冲突的问题,猜想是多线程资源交叉导致的,于是给可能导致资源竞争的地方加上了分布式锁.
由于无法重现故障,所以并没有确认问题得到解决.
第三次 故障依旧,当发现问题依然存在的时候,开始认真反思,发现自己解决问题的思路明显有问题,过于片面,一直都只在应用层面寻求解决问题的办法,而且解决问题的方式也只是在尝试百度出来的方法.并没有去思考更深层的问题.
在Mysql5.5中，information_schema 库中增加了三个关于锁的表（MEMORY引擎）；
INNODB_TRX ## 当前运行的所有事务
INNODB _LOCKS ## 当前出现的锁
INNODB_LOCK_WAITS ## 锁等待的对应关系
通过查询 INNODB_TRX 发现
当前事务中又两个RUNNING状态开始时间在一个小时之前
开始一直以为是锁表了
查看了 INNODB _LOCKS 事务信息之后发现有4行数据被锁住了一直没有释放
从这里开始发现问题了,应用已经抛了异常,事务理所当然的应该回滚才对,为什么资源依然没有释放,导致持续的阻塞呢?
其实最开始的异常信息就已经给出了答案,回到开始的地方,再看异常信息就很清楚了,应用里面的异常类是 MySQLTransactionRollBackException
是一个回滚异常, 这就说明在事务回滚的时候出了问题资源没有得到释放
然后开始查询 MySQLTransactionRollBackException 相关的信息
这个时候 innodb_rollback_on_timeout =0(默认配置)这个MySQL的配置开始进入我的视线,
举个栗子
事务在锁等待超时后是回滚事务内所有的statement还是最后一条语句；
0表示rollback最后一条语句，默认值； 有点坑爹啊( 细思极恐 )
1表示回滚事务内所有的statements；(此参数是只读参数，需在my.cnf中配置，并且重启生效；)
吃过一次亏,这次并没有盲目的相信百度到的信息
于是开始测试
一、验证innodb_rollback_on_timeout=off的情况
1.session A
开启事务,事务未提交,锁住id=1的数据
2.session B
开启事务,执行更新id=2的数据成功(事务未提交,锁住id=2),然后请求id=1等待锁超时,id=2的数据更改为222.
3.session C
请求id=2的数据50秒后显示等待锁超时
执行 SELECT * FROM information_schema.INNODB_TRX;
可发现有资源一直未释放,具体到测试数据中就是id=2的资源一直被锁定,线程一直被挂起.
总结:通过实验基本可以确定是业务资源交叉导致死锁之后资源没释放造成的持续阻塞，
二.验证innodb_rollback_on_timeout=on
修改配置后将验证innodb_rollback_on_timeout=off的步骤再走一遍
发现锁等待只能在业务层面尽量避免
on/off的区别在于session C进入时不会持续阻塞,session B异常后全部回滚
MYSQL_OPT_READ_TIMEOUT 是 MySQL c api 客户端中用来设置读取超时时间的参数。在 MySQL 的官方文档中，该参数的描述是这样的：
MYSQL_OPT_READ_TIMEOUT (argument type: unsigned int *)The timeout in seconds for each attempt to read from the server. There are retries if necessary, so the total effective timeout value is three times the option value. You can set the value so that a lost connection can be detected earlier than the TCP/IPClose_Wait_Timeout value of 10 minutes.
也就是说在需要的时候，实际的超时时间会是设定值的 3 倍。但是实际测试后发现实际的超时时间和设置的超时时间一致。
而具体什么时候发生三倍超时，在文档中没有找到。所以对 MySQL 5.7.20 的源码进行了一些分析。
使用 GDB 调试代码找了实际与 mysql server 通信的代码，如下：
请点击输入图片描述
其中 vio_read() 函数中，使用 recv 和 poll 来读取报文和做读取超时。net_should_retry() 函数只有在发生 EINTR 时才会返回 true。从这段代码来看是符合测试结果的，并没有对读取进行三次重试。只有在读取操作被系统中断打断时才会重试，但是这个重试并没有次数限制。
从上面代码的分析可以看出，代码的逻辑和文档的描述不符。于是在一顿搜索后，找到了一个 MySQL 的 BUG(Bug #31163)。该 BUG 报告了在 MySQL 5.0 中，MySQL c api 读取的实际超时时间是设置的三倍，与现有文档描述相符。于是对 MySQL 5.0.96 的代码又进行分析。
同样使用 GDB 找到了通信部分的代码。这次找到了重试三次的代码，如下：
请点击输入图片描述
这个版本的 MySQL api 的读写超时是直接使用的 setsockopt 设置的。第一次循环，在 A 点发生了第一次超时（虽然注释写的非阻塞，但是客户端的连接始终是阻塞模式的）。然后在 B 点将该 socket 设置为阻塞模式，C 点这里重置 retry 次数。由于设置了 alarm 第二次以后的循环会直接进入 D 点的这个分支，并且判断循环次数。作为客户端时net-retry_count 始终是 1，所以重试了两次，共计进行了 3 次 vioread 后从 E 点退出函数。
由上面的分析可知，MySQL 文档对于该参数的描述已经过时，现在的 MYSQL_OPT_READ_TIMEOUT 并不会出现三倍超时的问题。而 Bug #31163 中的处理结果也是将文档中该参数的描述更新为实际读取超时时间是设定时间的三倍。也许是 MySQL 的维护者们在后续版本更新时忘记更新文档吧。
