从上面Rolando的回答推断，是这些阻碍了你的查询:

---TRANSACTION 0 620783788, not started, process no 29956, OS thread id 1196472640
MySQL thread id 5341773, query id 189708353 10.64.89.143 viget

如果你需要执行你的查询，不能等待其他人运行，使用MySQL线程id杀死他们:

kill 5341773 <replace with your thread id>

(从mysql内部，而不是shell，显然)

你必须找到线程id从:

show engine innodb status\G

命令，并找出哪个是阻塞数据库的程序。

从上面Rolando的回答推断，是这些阻碍了你的查询:

---TRANSACTION 0 620783788, not started, process no 29956, OS thread id 1196472640
MySQL thread id 5341773, query id 189708353 10.64.89.143 viget

如果你需要执行你的查询，不能等待其他人运行，使用MySQL线程id杀死他们:

kill 5341773 <replace with your thread id>

(从mysql内部，而不是shell，显然)

你必须找到线程id从:

show engine innodb status\G

命令，并找出哪个是阻塞数据库的程序。

在记录中，锁等待超时异常也发生在出现死锁且MySQL无法检测到它时，因此它只是超时。另一个原因可能是一个运行时间非常长的查询，但是它更容易解决/修复，我在这里不描述这种情况。

如果死锁在两个事务中被“正确地”构造，MySQL通常能够处理死锁。然后MySQL只是杀死/回滚一个拥有较少锁的事务(不太重要，因为它影响的行较少)，并让另一个事务完成。

现在，让我们假设有两个进程A和B和3个事务:

Process A Transaction 1: Locks X
Process B Transaction 2: Locks Y
Process A Transaction 3: Needs Y => Waits for Y
Process B Transaction 2: Needs X => Waits for X
Process A Transaction 1: Waits for Transaction 3 to finish

(see the last two paragraph below to specify the terms in more detail)

=> deadlock 

这是一个非常不幸的设置，因为MySQL无法看到有死锁(跨越3个事务)。MySQL做的是…没有什么!它只是等待，因为它不知道该做什么。它等待直到第一个获得的锁超过超时(进程A事务1:锁X)，然后这将解锁锁X，从而解锁事务2等。

The art is to find out what (which query) causes the first lock (Lock X). You will be able to see easily (show engine innodb status) that Transaction 3 waits for Transaction 2, but you will not see which transaction Transaction 2 is waiting for (Transaction 1). MySQL will not print any locks or query associated with Transaction 1. The only hint will be that at the very bottom of the transaction list (of the show engine innodb status printout), you will see Transaction 1 apparently doing nothing (but in fact waiting for Transaction 3 to finish).

关于如何找到哪个SQL查询导致锁(lock X)被授予正在等待的给定事务的技术，在此处描述了在长时间运行的事务中跟踪MySQL查询历史

如果您想知道示例中的流程和事务究竟是什么。该进程是一个PHP进程。Transaction是由innodb-trx-table定义的事务。在我的例子中，我有两个PHP进程，在每个进程中我手动启动一个事务。有趣的是，即使我在一个进程中启动了一个事务，MySQL内部实际上使用了两个独立的事务(我不知道为什么，也许MySQL开发人员可以解释)。

MySQL is managing its own transactions internally and decided (in my case) to use two transactions to handle all the SQL requests coming from the PHP process (Process A). The statement that Transaction 1 is waiting for Transaction 3 to finish is an internal MySQL thing. MySQL "knew" the Transaction 1 and Transaction 3 were actually instantiated as part of one "transaction" request (from Process A). Now the whole "transaction" was blocked because Transaction 3 (a subpart of "transaction") was blocked. Because "transaction" was not able to finish the Transaction 1 (also a subpart of the "transaction") was marked as not finished as well. This is what I meant by "Transaction 1 waits for Transaction 3 to finish".

看看pt-deadlock-logger实用程序的手册页:

brew install percona-toolkit
pt-deadlock-logger --ask-pass server_name

它从上面提到的引擎innodb状态中提取信息 它可以用来创建一个守护进程，每30秒运行一次。

激活MySQL general.log(磁盘密集型)并使用mysql_analyse_general_log.pl来提取长时间运行的事务，例如:

——min-duration=你的innodb_lock_wait_timeout值

然后禁用general.log。

下面是我最终不得不做的事情，以找出是什么“其他查询”导致了锁定超时问题。在应用程序代码中，我们在专用于此任务的单独线程上跟踪所有挂起的数据库调用。如果任何DB调用的时间超过n秒(对我们来说是30秒)，我们记录:

-- Pending InnoDB transactions
SELECT * FROM information_schema.innodb_trx ORDER BY trx_started; 

-- Optionally, log what transaction holds what locks
SELECT * FROM information_schema.innodb_locks;

通过上述方法，我们能够精确定位锁定导致死锁的行的并发查询。在我的例子中，它们是像INSERT…与普通SELECT不同，SELECT锁定底层行。然后可以重新组织代码或使用不同的事务隔离(如read uncommitted)。

好运！