mysql数据库死锁问题解决以及kill 杀不掉问题

mysql数据库死锁问题解决

今天在做项目的时候，有人告诉我维护的一个老项目老是超时，我去看了下我的服务发现并没有问题。发现是调用数据库的时候超时。

重点

下面博主会介绍如何去kill掉该进程死锁，但是有个问题就是，如果kill掉的数据是用户已经操作过的，这个时候应该怎么办，如果在kill 进行时要做好 语句保留操作，将kill 掉之后需要恢复的sql 重新执行一次

show OPEN TABLES where in_use>0;

查询正在使用的库是啥

show processlist;

首先看下数据库中的等待执行数大约有多少，状态是什么样的

SELECT * FROM information_schema.INNODB_TRX;

在看下锁住的列都在干嘛，线程都在执行什么，比如早上还未完成的update任务，这种应该kill 掉

kill id

杀掉改进程id，这个时候你再次查询上两步操作，你会发现根本kill 不掉，在 show processlist 过程中你会发现该进程状态编程 killed ，这说明数据库并不是直接杀掉该进程，而是后台做了更加复杂的处理逻辑或者回滚这个操作

kill 不掉的语句 详细解疑

SELECT CONCAT_WS(’’,‘kill’,’ ‘,t.trx_mysql_thread_id,’;’)a FROM information_schema.INNODB_TRX t;

查询列出来所有应该kill掉的 thread_id，依次把他kill掉

show engine innodb status\G;

mysql> show engine innodb status \G
---
LOG
（Innodb 事务日志相关信息，包括当前的日志序列号（Log sequence number），已经刷新同步到那个序列号，最近的check point到那个序列号了。除此之外，还显示了系统从启动到现在已经做了多少次check point，多少次日志刷新。）
---
（注：小括号为官方解释。）
Log sequence number 2560255（当前的日志序列号）
Log flushed up to   2560255（刷新到日志重做日志文件的lsn）
Pages flushed up to 2560255（写入磁盘的脏页的lsn。记录在checkpoint中）
Last checkpoint at 2560246（刷新到磁盘的lsn）
0 pending(挂起) log flushes, 0 pending chkp writes
10 log i/o's done, 0.00 log i/o's/second

详解