MySQL锁表查询不到进程,如何处理_mysql查看表占用但是查不到占用进程-程序员宅基地

技术标签: mysql  MySQL进阶  

背景

测试同事通过更新某个表的数据进行功能测试,突然说锁表了,也不知道原因为何,一直用的Navicat,然后用show OPEN TABLES where In_use > 0;命令也查询不到具体的进程ID

常规解决办法
  1. 查询是否锁表
show OPEN TABLES where In_use > 0;
  1. 查询进程
show processlist;

查询到相对应的进程,然后

kill id;
通过查看事务处理
  1. 查看正在锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
  1. 查看等待锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
通过Innodb处理

在MySQL中有一个方法可以探窥到锁情况,它会打印出所有innodb的信息:

SHOW ENGINE INNODB STATUS;

如下,是通过语句获取到的信息(其中的IP全部用10.10.10.10已替换),后面会简要的进行分析这段文本


=====================================
2019-12-18 11:44:35 7f4f743f4700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 5 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 60826 srv_active, 0 srv_shutdown, 30696 srv_idle
srv_master_thread log flush and writes: 91522
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 9916
OS WAIT ARRAY INFO: signal count 9842
Mutex spin waits 2763, rounds 43928, OS waits 1328
RW-shared spins 8532, rounds 255229, OS waits 8469
RW-excl spins 82, rounds 3658, OS waits 94
Spin rounds per wait: 15.90 mutex, 29.91 RW-shared, 44.61 RW-excl
------------
TRANSACTIONS
------------
Trx id counter 188109012
Purge done for trx's n:o < 188101227 undo n:o < 0 state: running but idle
History list length 684
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 2326, OS thread handle 0x7f4f743f4700, query id 915743 10.10.10.10 root init
SHOW ENGINE INNODB STATUS
---TRANSACTION 188109010, not started
MySQL thread id 2324, OS thread handle 0x7f4f74476700, query id 915731 10.10.10.10 yt_dev cleaning up
---TRANSACTION 0, not started
MySQL thread id 2321, OS thread handle 0x7f4f3c0ae700, query id 914695 10.10.10.10 root cleaning up
---TRANSACTION 0, not started
MySQL thread id 2319, OS thread handle 0x7f4f4014b700, query id 915351 10.10.10.10 root cleaning up
---TRANSACTION 188108991, not started
MySQL thread id 2277, OS thread handle 0x7f4f360f8700, query id 915671 10.10.10.10 ytdev_phsp_data cleaning up
---TRANSACTION 0, not started
MySQL thread id 2314, OS thread handle 0x7f4f35be4700, query id 912387 10.10.10.10 root cleaning up
---TRANSACTION 188108516, not started
MySQL thread id 2275, OS thread handle 0x7f4f745af700, query id 914221 10.10.10.10 ytdev_phsp_data cleaning up
---TRANSACTION 188108974, not started
MySQL thread id 2286, OS thread handle 0x7f4f40312700, query id 915594 10.10.10.10 yt_dev cleaning up
---TRANSACTION 0, not started
MySQL thread id 2287, OS thread handle 0x7f4f3c171700, query id 908400 10.10.10.10 ytdev_phsp_data cleaning up
---TRANSACTION 188108951, not started
MySQL thread id 2280, OS thread handle 0x7f4f74372700, query id 915501 10.10.10.10 yt_dev cleaning up
---TRANSACTION 188108970, not started
MySQL thread id 2276, OS thread handle 0x7f4f740e8700, query id 915576 10.10.10.10 ytdev_phsp_data cleaning up
---TRANSACTION 188108004, not started
MySQL thread id 2261, OS thread handle 0x7f4f741ec700, query id 915637 10.10.10.10 ytdev_phsp_data cleaning up
---TRANSACTION 188109011, not started
MySQL thread id 2259, OS thread handle 0x7f4f36139700, query id 915739 10.10.10.10 ytdev_phsp_data cleaning up
---TRANSACTION 188107491, not started
MySQL thread id 2251, OS thread handle 0x7f4f36076700, query id 908114 10.10.10.10 yt_dev cleaning up
---TRANSACTION 188105855, not started
MySQL thread id 2237, OS thread handle 0x7f4f35e6e700, query id 915667 10.10.10.10 ytdev_phsp_data cleaning up
---TRANSACTION 188106734, not started
MySQL thread id 2191, OS thread handle 0x7f4f3c0ef700, query id 904938 10.10.10.10 yttest_opr cleaning up
---TRANSACTION 188108971, not started
MySQL thread id 2220, OS thread handle 0x7f4f4018c700, query id 915685 10.10.10.10 ytdev_phsp_data cleaning up
---TRANSACTION 188109008, not started
MySQL thread id 2180, OS thread handle 0x7f4f3617a700, query id 915721 10.10.10.10 ytdev_phsp_data cleaning up
---TRANSACTION 188105318, not started
MySQL thread id 2132, OS thread handle 0x7f4f4020e700, query id 915614 10.10.10.10 ytdev_phsp_data cleaning up
---TRANSACTION 0, not started
MySQL thread id 2090, OS thread handle 0x7f4f74066700, query id 849932 10.10.10.10 ytdev_phsp_data cleaning up
---TRANSACTION 188108998, not started
MySQL thread id 1950, OS thread handle 0x7f4f402d1700, query id 915711 10.10.10.10 ytdev_phsp_data cleaning up
---TRANSACTION 188108968, not started
MySQL thread id 1747, OS thread handle 0x7f4f40088700, query id 915566 10.10.10.10 yttest_opr cleaning up
---TRANSACTION 188043721, not started
MySQL thread id 1376, OS thread handle 0x7f4f400c9700, query id 915665 10.10.10.10 ytdev_phsp_data cleaning up
---TRANSACTION 188106729, not started
MySQL thread id 21, OS thread handle 0x7f4f7416a700, query id 904903 10.10.10.10 yttest_opr cleaning up
---TRANSACTION 188108889, ACTIVE 39 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 360, 1 row lock(s)
MySQL thread id 2315, OS thread handle 0x7f4f74539700, query id 915249 10.10.10.10 root updating
UPDATE `ytphsp_busi_v2`.`app_evaluation` SET `is_visible`='1' WHERE `id`='26'
------- TRX HAS BEEN WAITING 39 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 5023 page no 3 n bits 104 index `PRIMARY` of table `ytphsp_busi_v2`.`app_evaluation` trx id 188108889 lock_mode X locks rec but not gap waiting
Record lock, heap no 31 PHYSICAL RECORD: n_fields 12; compact format; info bits 0
 0: len 8; hex 800000000000001a; asc         ;;
 1: len 6; hex 00000b363265; asc    62e;;
 2: len 7; hex 6100000228141d; asc a   (  ;;
 3: len 8; hex 800000000bebc201; asc         ;;
 4: len 4; hex 8000000f; asc     ;;
 5: len 4; hex 80000000; asc     ;;
 6: SQL NULL;
 7: len 4; hex 80000000; asc     ;;
 8: SQL NULL;
 9: SQL NULL;
 10: SQL NULL;
 11: SQL NULL;

------------------
---TRANSACTION 188101221, ACTIVE 3405 sec
2 lock struct(s), heap size 360, 1 row lock(s), undo log entries 2
MySQL thread id 2065, OS thread handle 0x7f4f35ca7700, query id 881823 10.10.10.10 ytdev_phsp_data cleaning up
Trx read view will not see trx with id >= 188101222, sees < 188101222
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (write thread)
I/O thread 7 state: waiting for completed aio requests (write thread)
I/O thread 8 state: waiting for completed aio requests (write thread)
I/O thread 9 state: waiting for completed aio requests (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
 ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
146414 OS file reads, 68947 OS file writes, 48073 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 1556, seg size 1558, 17 merges
merged operations:
 insert 31, delete mark 15, delete 0
discarded operations:
 insert 0, delete mark 0, delete 0
Hash table size 138401, node heap has 187 buffer(s)
803.44 hash searches/s, 57.79 non-hash searches/s
---
LOG
---
Log sequence number 64441780891
Log flushed up to   64441780891
Pages flushed up to 64441780614
Last checkpoint at  64441780614
0 pending log writes, 0 pending chkp writes
21801 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 68681728; in additional pool allocated 0
Dictionary memory allocated 3026787
Buffer pool size   4096
Free buffers       1025
Database pages     2884
Old database pages 1044
Modified db pages  3
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 9822, not young 3172429
0.00 youngs/s, 0.00 non-youngs/s
Pages read 143394, created 910, written 38680
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 2884, unzip_LRU len: 0
I/O sum[30]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread process no. 1229, id 139978308536064, state: sleeping
Number of rows inserted 1171, updated 98547, deleted 974, read 21120891
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 863.03 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================

这里面最需要注意的一段就是如下这段,里面有死锁的事务ID,进程ID,能够进一步查询
搜寻这段的关键词:

  • TRX HAS BEEN WAITING
  • RECORD LOCKS space id
  • TRANSACTION
  • MySQL thread id
------- TRX HAS BEEN WAITING 39 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 5023 page no 3 n bits 104 index `PRIMARY` of table `ytphsp_busi_v2`.`app_evaluation` trx id 188108889 lock_mode X locks rec but not gap waiting
Record lock, heap no 31 PHYSICAL RECORD: n_fields 12; compact format; info bits 0
 0: len 8; hex 800000000000001a; asc         ;;
 1: len 6; hex 00000b363265; asc    62e;;
 2: len 7; hex 6100000228141d; asc a   (  ;;
 3: len 8; hex 800000000bebc201; asc         ;;
 4: len 4; hex 8000000f; asc     ;;
 5: len 4; hex 80000000; asc     ;;
 6: SQL NULL;
 7: len 4; hex 80000000; asc     ;;
 8: SQL NULL;
 9: SQL NULL;
 10: SQL NULL;
 11: SQL NULL;

------------------
---TRANSACTION 188101221, ACTIVE 3405 sec
2 lock struct(s), heap size 360, 1 row lock(s), undo log entries 2
MySQL thread id 2065, OS thread handle 0x7f4f35ca7700, query id 881823 10.10.10.10 ytdev_phsp_data cleaning up
Trx read view will not see trx with id >= 188101222, sees < 188101222

如上,可以找到事务ID=188101221,进程ID=2065
然后,kill 2065杀掉进程即可

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/Tomonkey/article/details/103595941

智能推荐

攻防世界_难度8_happy_puzzle_攻防世界困难模式攻略图文-程序员宅基地

文章浏览阅读645次。这个肯定是末尾的IDAT了,因为IDAT必须要满了才会开始一下个IDAT,这个明显就是末尾的IDAT了。,对应下面的create_head()代码。,对应下面的create_tail()代码。不要考虑爆破,我已经试了一下,太多情况了。题目来源:UNCTF。_攻防世界困难模式攻略图文

达梦数据库的导出(备份)、导入_达梦数据库导入导出-程序员宅基地

文章浏览阅读2.9k次,点赞3次,收藏10次。偶尔会用到,记录、分享。1. 数据库导出1.1 切换到dmdba用户su - dmdba1.2 进入达梦数据库安装路径的bin目录,执行导库操作  导出语句:./dexp cwy_init/[email protected]:5236 file=cwy_init.dmp log=cwy_init_exp.log 注释:   cwy_init/init_123..._达梦数据库导入导出

js引入kindeditor富文本编辑器的使用_kindeditor.js-程序员宅基地

文章浏览阅读1.9k次。1. 在官网上下载KindEditor文件,可以删掉不需要要到的jsp,asp,asp.net和php文件夹。接着把文件夹放到项目文件目录下。2. 修改html文件,在页面引入js文件:<script type="text/javascript" src="./kindeditor/kindeditor-all.js"></script><script type="text/javascript" src="./kindeditor/lang/zh-CN.js"_kindeditor.js

STM32学习过程记录11——基于STM32G431CBU6硬件SPI+DMA的高效WS2812B控制方法-程序员宅基地

文章浏览阅读2.3k次,点赞6次,收藏14次。SPI的详情简介不必赘述。假设我们通过SPI发送0xAA,我们的数据线就会变为10101010,通过修改不同的内容,即可修改SPI中0和1的持续时间。比如0xF0即为前半周期为高电平,后半周期为低电平的状态。在SPI的通信模式中,CPHA配置会影响该实验,下图展示了不同采样位置的SPI时序图[1]。CPOL = 0,CPHA = 1:CLK空闲状态 = 低电平,数据在下降沿采样,并在上升沿移出CPOL = 0,CPHA = 0:CLK空闲状态 = 低电平,数据在上升沿采样,并在下降沿移出。_stm32g431cbu6

计算机网络-数据链路层_接收方收到链路层数据后,使用crc检验后,余数为0,说明链路层的传输时可靠传输-程序员宅基地

文章浏览阅读1.2k次,点赞2次,收藏8次。数据链路层习题自测问题1.数据链路(即逻辑链路)与链路(即物理链路)有何区别?“电路接通了”与”数据链路接通了”的区别何在?2.数据链路层中的链路控制包括哪些功能?试讨论数据链路层做成可靠的链路层有哪些优点和缺点。3.网络适配器的作用是什么?网络适配器工作在哪一层?4.数据链路层的三个基本问题(帧定界、透明传输和差错检测)为什么都必须加以解决?5.如果在数据链路层不进行帧定界,会发生什么问题?6.PPP协议的主要特点是什么?为什么PPP不使用帧的编号?PPP适用于什么情况?为什么PPP协议不_接收方收到链路层数据后,使用crc检验后,余数为0,说明链路层的传输时可靠传输

软件测试工程师移民加拿大_无证移民,未受过软件工程师的教育(第1部分)-程序员宅基地

文章浏览阅读587次。软件测试工程师移民加拿大 无证移民,未受过软件工程师的教育(第1部分) (Undocumented Immigrant With No Education to Software Engineer(Part 1))Before I start, I want you to please bear with me on the way I write, I have very little gen...

随便推点

Thinkpad X250 secure boot failed 启动失败问题解决_安装完系统提示secureboot failure-程序员宅基地

文章浏览阅读304次。Thinkpad X250笔记本电脑,装的是FreeBSD,进入BIOS修改虚拟化配置(其后可能是误设置了安全开机),保存退出后系统无法启动,显示:secure boot failed ,把自己惊出一身冷汗,因为这台笔记本刚好还没开始做备份.....根据错误提示,到bios里面去找相关配置,在Security里面找到了Secure Boot选项,发现果然被设置为Enabled,将其修改为Disabled ,再开机,终于正常启动了。_安装完系统提示secureboot failure

C++如何做字符串分割(5种方法)_c++ 字符串分割-程序员宅基地

文章浏览阅读10w+次,点赞93次,收藏352次。1、用strtok函数进行字符串分割原型: char *strtok(char *str, const char *delim);功能:分解字符串为一组字符串。参数说明:str为要分解的字符串,delim为分隔符字符串。返回值:从str开头开始的一个个被分割的串。当没有被分割的串时则返回NULL。其它:strtok函数线程不安全,可以使用strtok_r替代。示例://借助strtok实现split#include <string.h>#include <stdio.h&_c++ 字符串分割

2013第四届蓝桥杯 C/C++本科A组 真题答案解析_2013年第四届c a组蓝桥杯省赛真题解答-程序员宅基地

文章浏览阅读2.3k次。1 .高斯日记 大数学家高斯有个好习惯:无论如何都要记日记。他的日记有个与众不同的地方,他从不注明年月日,而是用一个整数代替,比如:4210后来人们知道,那个整数就是日期,它表示那一天是高斯出生后的第几天。这或许也是个好习惯,它时时刻刻提醒着主人:日子又过去一天,还有多少时光可以用于浪费呢?高斯出生于:1777年4月30日。在高斯发现的一个重要定理的日记_2013年第四届c a组蓝桥杯省赛真题解答

基于供需算法优化的核极限学习机(KELM)分类算法-程序员宅基地

文章浏览阅读851次,点赞17次,收藏22次。摘要:本文利用供需算法对核极限学习机(KELM)进行优化,并用于分类。

metasploitable2渗透测试_metasploitable2怎么进入-程序员宅基地

文章浏览阅读1.1k次。一、系统弱密码登录1、在kali上执行命令行telnet 192.168.26.1292、Login和password都输入msfadmin3、登录成功,进入系统4、测试如下:二、MySQL弱密码登录:1、在kali上执行mysql –h 192.168.26.129 –u root2、登录成功,进入MySQL系统3、测试效果:三、PostgreSQL弱密码登录1、在Kali上执行psql -h 192.168.26.129 –U post..._metasploitable2怎么进入

Python学习之路:从入门到精通的指南_python人工智能开发从入门到精通pdf-程序员宅基地

文章浏览阅读257次。本文将为初学者提供Python学习的详细指南,从Python的历史、基础语法和数据类型到面向对象编程、模块和库的使用。通过本文,您将能够掌握Python编程的核心概念,为今后的编程学习和实践打下坚实基础。_python人工智能开发从入门到精通pdf

推荐文章

热门文章

相关标签