迟到的派对(像往常一样)，但我的问题是我写了一些糟糕的SQL(作为一个新手)和几个进程对记录有一个锁<-不确定适当的措辞。我最终不得不:SHOW PROCESSLIST，然后使用kill <id>杀死id

如何强制解锁MySQL中锁定的表:

像这样打破锁可能会导致数据库中的原子性不被强制用于导致锁的sql语句。

这很棘手，正确的解决方案是修复导致锁的应用程序。然而，当美元处于危险之中时，迅速的一脚将使事情再次启动。

1)进入MySQL

mysql -u your_user -p

2)让我们看看锁定的桌子列表

mysql> show open tables where in_use>0;

3)让我们看看当前进程的列表，其中一个正在锁定你的表

mysql> show processlist;

4)终止其中一个进程

mysql> kill <put_process_id_here>;

某些东西阻塞了查询的执行。很可能是另一个查询更新、插入或删除查询中的某个表。你必须找出那是什么:

SHOW PROCESSLIST;

一旦你找到阻塞进程，找到它的id并运行:

KILL {id};

重新运行初始查询。

确保数据库表使用InnoDB存储引擎和READ-COMMITTED事务隔离级别。

你可以通过SELECT @@GLOBAL来检查它。tx_isolation @@tx_isolation;在mysql控制台。

如果没有设置为READ-COMMITTED，则必须设置它。在设置之前，请确保您在mysql中拥有SUPER权限。

你可以从http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html上获得帮助。

通过设置这个，我认为你的问题会得到解决。

您可能还希望检查是否试图同时在两个进程中更新此文件。用户(@tala)在这种情况下遇到了类似的错误消息，可能需要仔细检查…

完全符合MarkR的说法。自动提交使每个语句成为一个语句事务。

SHOW ENGINE INNODB STATUS会给你一些死锁原因的线索。还要仔细查看慢速查询日志，看看还有什么正在查询表，并尝试删除正在执行满表罐操作的任何内容。行级锁定工作得很好，但当您试图锁定所有行的时候就不行了!

我们昨天遇到了这个问题，在仔细研究了这里的每一个建议的解决方案，以及其他答案/论坛的其他几个解决方案后，我们最终在意识到实际问题时解决了它。

由于一些糟糕的计划，我们的数据库存储在一个挂载的卷上，该卷也接收我们的常规自动备份。该容量已达到最大容量。

一旦我们清理了一些空间并重新启动，这个错误就被解决了。

注意，我们也手动终止了几个进程:kill <process_id>;所以这仍然是必要的。

总的来说，我们的结论是，令人难以置信的是，我们的日志或警告都没有直接提到磁盘空间不足，但这似乎确实是根本原因。