我有一个由两个节点组成的MariaDB（ 5.5.41 ）群集被configuration为主从。 所有读取和写入都发送到同一个节点。
我几个星期以来一直在调查一些僵局问题。
定期，我的PHP应用程序返回Message: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction. Message: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction.
我以前可以运行SHOW ENGINE INNODB STATUS; 并会看到最后一个死锁，但由于某种原因，在一个小的无关configuration更改（将innodb_buffer_pool_instances从1更改为19）和重新启动两个节点之后，执行SHOW ENGINE INNODB STATUS; 不会出现任何僵局。
但是，如果我连接我的mysql客户端，并手动创build事务导致死锁，状态命令确实显示死锁。
我试图打开和closuresinnodb_print_all_deadlocks 。 mysql-error.log没有显示，除了我手动触发的死锁。
为什么我的PHP应用程序创build的死锁不再显示？
show engine innodb status不是给你所需的死锁信息是相当令人费解的。 但是，您可以通过运行mysqladmin debug来检查死锁情况， mysqladmin debug会logging所有的锁以及本例中show engine innodb status未显示的LOCK TABLE锁。
这些问题有时出现在错误的时间，浪费了很多时间。 我个人使用Monyog来监视哪个也是这样。 如果没有任何作用，你可以尝试使用它的试用
我不认为我可以直接回答你的问题，因为我无法访问你的系统和所给的信息。 但是，这里有一些令人敬畏的工具，用于更好地处理我负责pipe理的各种MySQL派生数据库。
InnoTop ： https ： //github.com/innotop/innotop
检查innotop手册页中的“D”命令：
D: InnoDB Deadlocks This mode shows the transactions involved in the last InnoDB deadlock. A second table shows the locks each transaction held and waited for. A deadlock is caused by a cycle in the waits-for graph, so there should be two locks held and one waited for unless the deadlock information is truncated. [...]
“K”和“L”命令也可能与您有关。
注意： innotop要充分有用，可能需要更改模式信息和设置，并添加一个“testing”数据库来收集信息。 阅读完整的人员页面 ，在盲目地更改数据库之前了解自己正在进入的内容。 （就我个人而言，我喜欢额外的信息，改变innotop揭幕…）
不太直接与您的locking问题有关，但非常有用，但：
Percona工具包 （以前称为MAATKIT）： https ：//www.percona.com/software/database-tools/percona-toolkit
祝你好运！