Problemas de transactions sin fin después de la actualización de mysql 5.0-> 5.6

He actualizado todo nuestro backend mysql db de 5.0 a 5.6, incluyendo el cambio de algunas tablas a innodb, y hemos estado teniendo nada pero problemas con transactions sin fin desde entonces. Todavía tengo un server de ensayo que utiliza 5.0 y puedo confirmar que sólo recibimos transactions estancadas en el nuevo server de bases de datos. Ambos serveres se ejecutan en tx_isolation = REPEATABLE-READ modo ( http://dev.mysql.com/doc/refman/5.6/en/set-transaction.html ). Estoy bastante seguro de que todas las tablas involucradas son InnoDB para ambos serveres.

Así que un ejemplo simple del problema que hemos estado teniendo es algún process que envía correos electrónicos de bienvenida, que se ejecuta como un hijo supervisor (no es realmente importante). En la etapa env con mysql 5.0, la connection dura unos minutos y no tiene transactions abiertas:

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

El mismo progtwig en nuestro entorno de producción con mysql 5.6 y su de repente el niño demonio que bloquea las tablas realmente importantes y nunca las libera.

 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 

Cuando no está causando problemas horribles, la transacción se ve así:

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

¿Alguien tiene alguna sugerencia? Estoy pensando en habilitar el modo de transacción de read-uncommited pero …. parece un parche para un problema diferente, y realmente necesito saber cuál es el problema original!

Así que nunca me di count de exactamente cómo activar el problema, pero tenía algo que ver con tablas innodb realmente grande en una de nuestras bases de datos. Uno de ellos tenía más de 303 millones de líneas. Cuando configuré algunos scripts para eliminar datos antiguos cada noche, el problema se fue para siempre. Éstas no eran realmente tablas muy importantes, y eran en su mayor parte sólo escritas, por lo general no se leen. También tenían demasiados índices.

De todos modos si tiene este problema, trate de get todas sus tablas de 10-15 millones de inputs.