MySQL 5.6中怎么定位DDL被阻塞的问题


这篇文章将为大家详细讲解有关MySQL 5.6中怎么定位DDL被阻塞的问题,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。对于DDL被阻塞问题的定位,我们主要是基于MySQL 5.7新引入的performance_schema.metadata_locks表。提出的定位方法,颇有种”锦上添花”的意味,而且,也只适用于MySQL 5.7开始的版本。但在实际生产中,MySQL 5.6还是占绝不多数。虽然MySQL 8.0都已经GA了,但鉴于数据库的特殊性,在对待升级的这个事情上,相当一部分人还是秉持着一种“不主动”的态度。既然MySQL 5.6用者众多,有没有一种方法,来解决MySQL 5.6的这个痛点呢?还是之前的测试Demo。会话1开启了事务并执行了三个操作,但未提交,此时,会话2执行了alter table操作,被阻塞。session1>
begin;
Query
OK,

rows affected
(0.00
sec)


session1>
delete
from
slowtech.t1
where
id=2;
Query
OK,
1
row affected
(0.00
sec)


session1>
select
*
from
slowtech.t1;
+------+------+|
id
|
name
|
+------+------+|
1
|
a |
+------+------+1
row
in
set
(0.00
sec)


session1>
update slowtech.t1
set
name='c'
where
id=1;
Query
OK开发云主机域名,
1
row affected
(0.00
sec)
Rows
matched:
1
Changed:
1
Warnings:


session2>
alter table slowtech.t1 add c1
int;
##被阻塞


session3>
show processlist;
+----+------+-----------+------+---------+------+---------------------------------+------------------------------------+|
Id
|
User
|
Host
|
db
|
Command
|
Time
|
State

|
Info

|+----+------+-----------+------+---------+------+---------------------------------+------------------------------------+|
2
|
root
|
localhost
|
NULL
|
Sleep

|

51
|

|
NULL
|
|
3
|
root
|
localhost
|
NULL
|
Query

|

|
starting |
show processlist
|
|
4
|
root
|
localhost
|
NULL
|
Query

|
9
|
Waiting
for
table metadata
lock
|
alter table slowtech.t1 add c1
int
|
+----+------+-----------+------+---------+------+---------------------------------+------------------------------------+3
rows
in
set
(0.00
sec)
提示,类似代码可左右滑动其实,导致DDL阻塞的操作,无非两类:1. 慢查询2. 表上有事务未提交其中,第一类比较好定位,通过show processlist即能发现。而第二类基本没法定位,因为未提交事务的连接在show processlist中的输出同空闲连接一样。如下面Id为2的连接,虽然Command显示为“Sleep”,其实是事务未提交。所以,网上有kill空闲(Command为Sleep)连接的说法,其实也不无道理,但这样做就太简单粗暴了,难免会误杀。其实,既然是事务,在information_schema. innodb_trx中肯定会有记录,如会话1中的事务,在表中的记录如下,其中trx_mysql_thread_id是线程id,结合performance_schema.threads,可以知道当前哪些连接上存在着活跃事务,这样就进一步缩小了可被kill的线程范围。但从影响程度上,和kill所有Command为Sleep的连接没太大区别,毕竟,kill真正的空闲连接对业务的影响不大。有没有办法能更精确地定位出阻塞会话呢?有,答案还是在于之前介绍的performance_ schema.events_statements_history表。在上篇MySQL 5.7的分析中,我们是首先知道引发阻塞的线程ID,然后利用events_statements_history表,查看该线程的相关SQL。而在MySQL 5.6中,我们并不知道引发阻塞的线程ID,但是,我们可以反其道而行之,利用穷举法,首先统计出所有线程在当前事务执行过的所有SQL,然后再判断这些SQL中是否包含目标表。具体SQL如下,从输出来看,确实也达到了预期效果。需要注意的是,在MySQL5.6中,events_ statements_history默认是没有开启的。关于“MySQL 5.6中怎么定位DDL被阻塞的问题”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,使各位可以学到更多知识,如果觉得文章不错,请把它分享出去让更多的人看到。

相关推荐: 基于centos6的mysql5.7.13主从部署是怎么样的

基于centos6的mysql5.7.13主从部署是怎么样的,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。基于c开发云主机域名entos6的mysql5.7.13主从部署主从测试登入(主)mysq…

免责声明:本站发布的图片视频文字,以转载和分享为主,文章观点不代表本站立场,本站不承担相关法律责任;如果涉及侵权请联系邮箱:360163164@qq.com举报,并提供相关证据,经查实将立刻删除涉嫌侵权内容。

(0)
打赏 微信扫一扫 微信扫一扫
上一篇 06/22 15:20
下一篇 06/22 15:20

相关推荐