☰

mysql 5.0->5.6 升级后，事务问题永无休止

tag-icon • tag-icon mysql innodb
mysql 5.0->5.6 升级后，事务问题永无休止

我将整个后端 mysql 数据库从 5.0 升级到了 5.6，其中包括更改很少表到 innodb，从那时起我们就一直遇到事务永不结束的问题。我仍然有一个使用 5.0 的临时服务器，我可以确认我们在新的数据库服务器上只遇到了停滞的事务。两个服务器都在 tx_isolation = REPEATABLE-READ 模式下运行（http://dev.mysql.com/doc/refman/5.6/en/set-transaction.html ）。我很确定两台服务器中涉及的所有表都是 InnoDB。

因此，我们遇到的问题的一个简单示例是一些发送欢迎电子邮件的进程，该进程作为监督子进程运行（并不重要）。在带有 mysql 5.0 的阶段环境中，连接持续几分钟并且没有打开的事务：

From show full processlist:
1639945 dbuser  <app-stage>:54536   db  Sleep   246     NULL

InnoDB transaction logs:
<nothing>

我们在生产环境中使用的 mysql 5.6 版本使用了完全相同的程序，但它突然变成了一个恶魔，锁定了真正重要的表并且从不释放它们。

From show full processlist:
28674638    dbuser  <app-prod>:54836    db  Sleep   67131   NULL

Innodb transaction:
---TRANSACTION 90461789, ACTIVE 67062 sec
MySQL thread id 28674638, OS thread handle 0x7f8ab934f700, query id 758722407 <app-prod> dbuser cleaning up
Trx read view will not see trx with id >= 90461790, sees < 89033402

当它没有造成可怕的问题时，交易看起来像这样：

---TRANSACTION 111578756, not started
MySQL thread id 42149496, OS thread handle 0x7f8ac29b4700, query id 975441865 <app-prod> dbuser cleaning up

有人有什么建议吗？我正在考虑启用 read-uncommited 事务模式，但是......这看起来像是针对另一个问题的补丁，我真的需要知道原始问题是什么！

答案1

因此，我一直没有弄清楚如何触发该问题，但它与我们数据库中的某个大型 innodb 表有关。其中一个表的长度超过 3.03 亿行。当我设置一些脚本来每晚删除旧数据时，问题就彻底解决了。这些表实际上并不是非常重要，而且大多数情况下只被写入，通常不会被读取。它们也都有太多索引。

无论如何，如果您遇到此问题，请尝试将所有表的条目数控制在 1000 万到 1500 万个以下。

相关内容