我将整个后台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。
因此，我们遇到的一个简单的例子就是发送欢迎电子邮件的过程，这个电子邮件作为一个supervisord子节点运行（不是很重要）。 在使用mysql 5.0的舞台上，连接持续几分钟，并且没有打开的事务：
From show full processlist: 1639945 dbuser <app-stage>:54536 db Sleep 246 NULL InnoDB transaction logs: <nothing> 我们的生产环境与MySQL 5.6完全相同的程序，它突然间locking真正重要的表的恶魔的孩子，从来没有释放他们。
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
任何人有任何build议？ 我有点思考启用读取未完成的交易模式，但是……它似乎是针对不同问题的补丁，我真的需要知道原始问题是什么！
所以我从来没有完全想到如何触发这个问题，但是它与我们的数据库中的非常大的innodb表有关。 其中一条长度超过3.03亿行。 当我设置一些脚本来每天晚上删除旧数据时，问题就消失了。 这些确实不是非常重要的表格，而且大多数情况下只写入，通常不会读取。 他们也都有太多的指标。
无论如何，如果你有这个问题，尝试让所有的表格less于一千五百万条目。