下面是我最终不得不做的事情，以找出是什么“其他查询”导致了锁定超时问题。在应用程序代码中，我们在专用于此任务的单独线程上跟踪所有挂起的数据库调用。如果任何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)。

好运！

如果您正在使用JDBC，那么您可以选择 includeInnodbStatusInDeadlockExceptions = true

https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-configuration-properties.html

你可以使用:

show full processlist

它将列出MySQL中的所有连接和连接的当前状态以及正在执行的查询。还有一个更短的变种show processlist;它显示截断的查询以及连接统计信息。

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

——min-duration=你的innodb_lock_wait_timeout值

然后禁用general.log。

从上面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

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

争用越多，出现死锁的可能性就越大，DB引擎将通过对其中一个死锁事务进行超时处理来解决这个问题。

此外，已修改(例如UPDATE或DELETE)大量条目的长时间运行的事务更有可能与其他事务产生冲突。

虽然InnoDB MVCC，你仍然可以使用FOR UPDATE子句请求显式锁。然而，与其他流行的db (Oracle, MSSQL, PostgreSQL, DB2)不同，MySQL使用REPEATABLE_READ作为默认隔离级别。

现在，您获得的锁(通过修改行或使用显式锁定)将在当前运行的事务期间保持。如果你想了解REPEATABLE_READ和READ COMMITTED在锁方面的区别，请阅读这篇Percona文章。

在REPEATABLE READ中，事务期间获得的每个锁都被持有 在事务持续时间内。 在READ COMMITTED中，不匹配扫描的锁在STATEMENT完成后被释放。 .．. 这意味着在READ COMMITTED中，其他事务可以自由地更新它们在update语句完成后无法更新的行(在REPEATABLE READ中)。

因此:隔离级别(REPEATABLE_READ, SERIALIZABLE)越严格，死锁的可能性就越大。这不是“本质上”的问题，而是一种权衡。

使用READ_COMMITTED可以获得非常好的结果，因为在使用跨越多个HTTP请求的逻辑事务时，需要防止应用程序级的丢失更新。乐观锁定方法针对即使使用SERIALIZABLE隔离级别也可能发生的丢失更新，同时通过允许使用READ_COMMITTED来减少锁争用。