查找原始MySQL死锁ID

转载地址:http://yueliangdao0608.blog.51cto.com/397025/1180917

如果遇到死锁了,怎么解决呢?找到原始的锁ID,然后KILL掉一直持有的那个线程就可以了, 但是众多线程,可怎么找到引起死锁的线程ID呢? MySQL 发展到现在,已经非常强大了,这个问题很好解决。 直接从数据字典连查找。

我们来演示下。

 

线程A,我们用来锁定某些记录,假设这个线程一直没提交,或者忘掉提交了。 那么就一直存在,但是数据里面显示的只是SLEEP状态。

mysql> set @@autocommit=0;
Query OK, 0 rows affected (0.00 sec) 

mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A 

Database changed
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| demo_test      |
| t3             |
+----------------+
2 rows in set (0.00 sec) 

mysql> select * from t3;
+----+--------+--------+------------+----+----+----+
| id | fname  | lname  | birthday   | c1 | c2 | c3 |
+----+--------+--------+------------+----+----+----+
| 19 | lily19 | lucy19 | 2013-04-18 | 19 |  0 |  0 |
| 20 | lily20 | lucy20 | 2013-03-13 | 20 |  0 |  0 |
+----+--------+--------+------------+----+----+----+
2 rows in set (0.00 sec) 

mysql> update t3 set birthday = ‘2022-02-23‘ where id = 19;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0 

mysql> select connection_id();
+-----------------+
| connection_id() |
+-----------------+
|              16 |
+-----------------+
1 row in set (0.00 sec) 

mysql>  

线程B, 我们用来进行普通的更新,但是遇到问题了,此时不知道是哪个线程把这行记录给锁定了?

mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A 

Database changed
mysql> select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
|            1 |
+--------------+
1 row in set (0.00 sec) 

mysql> update t3 set birthday=‘2018-01-03‘ where id = 19;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
mysql> select connection_id();
+-----------------+
| connection_id() |
+-----------------+
|              17 |
+-----------------+
1 row in set (0.00 sec) 

mysql> show processlist;
+----+------+-----------+------+---------+------+-------+------------------+
| Id | User | Host      | db   | Command | Time | State | Info             |
+----+------+-----------+------+---------+------+-------+------------------+
| 10 | root | localhost | NULL | Sleep   | 1540 |       | NULL             |
| 11 | root | localhost | NULL | Sleep   |  722 |       | NULL             |
| 16 | root | localhost | test | Sleep   |  424 |       | NULL             |
| 17 | root | localhost | test | Query   |    0 | init  | show processlist |
| 18 | root | localhost | NULL | Sleep   |    5 |       | NULL             |
+----+------+-----------+------+---------+------+-------+------------------+
5 rows in set (0.00 sec) 

mysql> show engine innodb status\G 

------------
TRANSACTIONS
------------
Trx id counter 189327
Purge done for trx‘s n:o < 189323 undo n:o < 0 state: running but idle
History list length 343
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 11, OS thread handle 0x7f70a0c98700, query id 994 localhost root init
show engine innodb status
---TRANSACTION 189326, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 17, OS thread handle 0x7f70a0bd5700, query id 993 localhost root updating
update t3 set birthday=‘2018-01-03‘ where id = 19
------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 529 page no 3 n bits 72 index `PRIMARY` of table `test`.`t3` trx id 189326 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 9; compact format; info bits 0
 0: len 2; hex 3139; asc 19;;
 1: len 6; hex 00000002e38c; asc       ;;
 2: len 7; hex 7e00000d2827c9; asc ~   (‘ ;;
 3: len 6; hex 6c696c793139; asc lily19;;
 4: len 6; hex 6c7563793139; asc lucy19;;
 5: len 3; hex 8fcc57; asc   W;;
 6: len 4; hex 80000013; asc     ;;
 7: len 4; hex 80000000; asc     ;;
 8: len 4; hex 80000000; asc     ;; 

------------------
---TRANSACTION 189324, ACTIVE 641 sec
2 lock struct(s), heap size 376, 3 row lock(s), undo log entries 1
MySQL thread id 16, OS thread handle 0x7f70a0b94700, query id 985 localhost root cleaning up
Trx read view will not see trx with id >= 189325, sees < 189325
 

上面的信息很繁多,也看不清楚到底哪里是哪里。

不过现在,我们只要从数据字典里面拿出来这部分信息就OK了。

mysql> SELECT * FROM information_schema.INNODB_TRX\G
*************************** 1. row ***************************
                    trx_id: 189324
                 trx_state: RUNNING
               trx_started: 2013-04-18 17:48:14
     trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 3
       trx_mysql_thread_id: 16
                 trx_query: NULL
       trx_operation_state: NULL
         trx_tables_in_use: 0
         trx_tables_locked: 0
          trx_lock_structs: 2
     trx_lock_memory_bytes: 376
           trx_rows_locked: 3
         trx_rows_modified: 1
   trx_concurrency_tickets: 0
       trx_isolation_level: REPEATABLE READ
         trx_unique_checks: 1
    trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_adaptive_hash_latched: 0
 trx_adaptive_hash_timeout: 10000
          trx_is_read_only: 0
trx_autocommit_non_locking: 0
1 row in set (0.01 sec) 

mysql>  

原来是线程16忘掉COMMIT了。

时间: 2024-08-03 04:54:38

查找原始MySQL死锁ID的相关文章

mysql 查找不存在的id

最近在群里有人问到怎样才能将mysql表中 查找不存在的id(id自增,或者连续都可以) 第一种方法: select bewin_id,a from ( select bewin_id,1 as a from (select bewin_id from c_userinfo_his order by bewin_id asc) t where not exists (select 1 from c_userinfo_his where bewin_id=t.bewin_id-1) union s

MySQL死锁[转]

案例描述       在定时脚本运行过程中,发现当备份表格的sql语句与删除该表部分数据的sql语句同时运行时,mysql会检测出死锁,并打印出日志. 两个sql语句如下:       (1)insert into backup_table select * from source_table      (2)DELETE FROM source_table WHERE Id>5 AND titleWeight<32768 AND joinTime<'$daysago_1week'   

MySQL 死锁与日志二三事

最近线上 MySQL 接连发生了几起数据异常,都是在凌晨爆发,由于业务场景属于典型的数据仓库型应用,白天压力较小无法复现.甚至有些异常还比较诡异,最后 root cause 分析颇费周折.那实际业务当中咱们如何能快速的定位线上 MySQL 问题,修复异常呢?下文我会根据两个实际 case,分享下相关的经验与方法. 1.Case1:部分数据更新失败 某天渠道同学反馈某报表极个别渠道数据为 0,大部分渠道数据正常.这个数据是由一个统计程序每天凌晨例行更新的,按理来说,要么全部正常,要么全部失败,那会

MySQL 死锁日志分析

------------------------ LATEST DETECTED DEADLOCK ------------------------ 140824  1:01:24 *** (1) TRANSACTION: TRANSACTION 110E, ACTIVE 73 sec starting index read   ## 事务ID=110E,活跃了73s mysql tables in use 1, locked 1 LOCK WAIT 3 lock struct(s), heap

为什么MySQL死锁检测会严重降低TPS

在大量的客户端,更新数据表的同一行时,会造成数据库的吞吐量大幅降低. 很多数据库的前辈和同行分别通过实验和源码的方法,定位到了罪魁祸首----MySQL死锁检测 实验方式:http://blog.csdn.net/zhaiwx1987/article/details/6952285 源码方式:http://www.gpfeng.com/?p=426 请大家尤其注意这段代码 ##### lock_mutex_enter(); ut_ad(lock_table_has(thr_get_trx(thr

一个最不可思议的MySQL死锁分析

一个最不可思议的MySQL死锁分析 死锁问题背景 做MySQL代码的深入分析也有些年头了,再加上自己10年左右的数据库内核研发经验,自认为对于MySQL/InnoDB的加锁实现了如指掌,正因如此,前段时间,还专门写了一篇洋洋洒洒的文章,专门分析MySQL的加锁实现细节:<MySQL加锁处理分析>. 但是,昨天"润洁"同学在<MySQL加锁处理分析>这篇博文下咨询的一个MySQL的死锁场景,还是彻底把我给难住了.此死锁,完全违背了本人原有的锁知识体系,让我百思不得

MySQL死锁分析

1. 测试描述 环境说明:RHEL 6.4 x86_64 + MySQL 5.5.37,事务隔离级别为RC 测试表: mysql> show create table t1\G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `a` int(11) NOT NULL DEFAULT '0', `b` int(11) DEFAULT

MySQL死锁问题实例分析及解决方法

MySQL死锁问题的相关知识是本文我们主要要介绍的内容,接下来我们就来一一介绍这部分内容,希望能够对您有所帮助. 1.MySQL常用存储引擎的锁机制 MyISAM和MEMORY采用表级锁(table-level locking) BDB采用页面锁(page-level locking)或表级锁,默认为页面锁 InnoDB支持行级锁(row-level locking)和表级锁,默认为行级锁 2.各种锁特点 表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低 行级锁

mysql-不恰当的update语句使用主键和索引导致mysql死锁

背景知识:MySQL有三种锁的级别:页级.表级.行级. MyISAM和MEMORY存储引擎采用的是表级锁(table-level locking):BDB存储引擎采用的是页面锁(page-level locking),但也支持表级锁:InnoDB存储引擎既支持行级锁(row-level locking),也支持表级锁,但默认情况下是采用行级锁. MySQL这3种锁的特性可大致归纳如下: 表级锁:开销小,加锁快:不会出现死锁:锁定粒度大,发生锁冲突的概率最高,并发度最低.行级锁:开销大,加锁慢:会