use*_*680 6 mysql node.js typeorm
我们在 TypeORM 方面遇到了一个奇怪的问题，特别是在 Jest 方面（可能相关，也可能无关）。某个测试完全卡住/挂起，我们\xe2\x80\x99很难找出问题所在。
\n就堆栈而言：Typescript, NodeJS, Apollo Graphql, Jest, MySQL.\n所讨论的测试实际上是使用 Apollo\xe2\x80\x99s 集成测试框架的集成测试。
首先发生的是一个特定的测试完全卡住了，几分钟后控制台中抛出一个错误：QueryFailedError: ER_LOCK_WAIT_TIMEOUT: Lock wait timeout exceeded; try restarting transaction
试图查明问题使我找到了我们在afterEach\xe2\x80\x9cdestroys\xe2\x80\x9d 数据库上运行的函数。它最初运行：
await queryRunner.query('DELETE FROM Table1');\nawait queryRunner.query('DELETE FROM Table2');\n...\nqueryRunner在我将其更改为后，错误和“死锁”最初被修复queryBuilder：
await queryBuilder.delete().from('Table1').execute();\n...\n这是在反复尝试弄清楚发生了什么之后完成SHOW PROCESSLIST;的SHOW ENGINE InnoDB STATUS;。我还将事务隔离更改为 READ-COMMITTED 但无济于事。queryRunner除了将其从 更改为之外，没有什么真正有效的queryBuilder。
这工作了一段时间，但现在测试似乎再次陷入困境（测试尚未改变，但测试的代码已改变）。现在，测试挂起后，我们收到此错误：Error: Pool is closed。之后测试被“发布”，所有测试都开始一一失败。
我们发现这是导致测试卡住的事件序列：
\n1. open a transaction with queryRunner\n2. perform a read query\n3. then perform a write\n4. commit the transaction and release the queryRunner\n5. delete the DB\n6. perform a write - deadlock\n此外，我们还注意到以下几点：
\n\n\n如果我们确保只使用 queryRunner 进行更新，而不使用\n查询，那么死锁就不会\xe2\x80\x99 发生。
\n更改代码，以便我们首先使用常规连接对象（而不是 queryRunner）进行所有读取查询，然后只有当我们连接
\nqueryRunner并进行所有写入时，才不会发生死锁。
有人对可能发生的事情有任何见解吗？queryRunner 是否存在一些不稳定因素或者我们在使用它时需要考虑的一些具体事项？
\n谢谢！
\n