我有2个Doctrine DBAL连接，其中一个是非事务性的(用于重要日志)，它们旨在并行运行，而不是相互依赖。

CodeExecution(
    TransactionConnectionQuery()
    TransactionlessConnectionQuery()
)

我的集成测试被包装到事务中，以便在每次测试后进行数据回滚。

beginTransaction()
CodeExecution(
    TransactionConnectionQuery()
    TransactionlessConnectionQuery() // CONFLICT
)
rollBack()

我的解决方案是在这些测试中禁用包装事务，并以另一种方式重置db数据。

查看一下您的数据库是否进行了微调，特别是事务隔离。增加innodb_lock_wait_timeout变量不是一个好主意。

检查MySQL中的数据库事务隔离级别:

mysql> SELECT @@GLOBAL.tx_isolation, @@tx_isolation, @@session.tx_isolation;
+-----------------------+-----------------+------------------------+
| @@GLOBAL.tx_isolation | @@tx_isolation  | @@session.tx_isolation |
+-----------------------+-----------------+------------------------+
| REPEATABLE-READ       | REPEATABLE-READ | REPEATABLE-READ        |
+-----------------------+-----------------+------------------------+
1 row in set (0.00 sec)

您可以通过更改隔离级别来获得改进。使用类似oracle的READ COMMITTED而不是REPEATABLE READ。REPEATABLE READ是InnoDB的默认值。

mysql> SET tx_isolation = 'READ-COMMITTED';
Query OK, 0 rows affected (0.00 sec)

mysql> SET GLOBAL tx_isolation = 'READ-COMMITTED';
Query OK, 0 rows affected (0.00 sec)

此外，仅在必要时尝试使用SELECT FOR UPDATE。

有同样的错误，即使我只是更新一个表与一个条目，但重新启动mysql后，它被解决了。

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

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

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

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

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

我有2个Doctrine DBAL连接，其中一个是非事务性的(用于重要日志)，它们旨在并行运行，而不是相互依赖。

CodeExecution(
    TransactionConnectionQuery()
    TransactionlessConnectionQuery()
)

我的集成测试被包装到事务中，以便在每次测试后进行数据回滚。

beginTransaction()
CodeExecution(
    TransactionConnectionQuery()
    TransactionlessConnectionQuery() // CONFLICT
)
rollBack()

我的解决方案是在这些测试中禁用包装事务，并以另一种方式重置db数据。

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

SHOW PROCESSLIST;

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

KILL {id};

重新运行初始查询。