Niekończące się problemy z transakcjami po aktualizacji mysql 5.0- & > 5.6

Zaktualizowałem nasz cały serwer db mysql z 5.0 do 5.6, łącznie ze zmianą

trochę

table w innodb i od tego czasu mamy tylko problemy z nieskończonymi transakcjami. Nadal mam serwer pomostowy używający 5.0 i mogę potwierdzić, że zatrzymujemy transakcje tylko na nowym serwerze bazy danych. Oba serwery pracują w tx_isolation = REPEATABLE-READ (

http://dev.mysql.com/doc/refma ... .html
http://dev.mysql.com/doc/refma ... n.html). Jestem prawie pewien, że wszystkie zaangażowane tabele to InnoDB dla obu serwerów.
Tak więc, prostym przykładem problemu, z którym mamy do czynienia, jest proces wysyłania e-maili powitalnych, który zaczyna się jako dziecko przełożonego (niezbyt ważne). Na etapie środowiska z mysql 5.0 połączenie trwa kilka minut i nie ma otwartych transakcji:

From show full processlist:

1639945 dbuser  <app-stage>:54536   db  Sleep   246     NULLInnoDB transaction logs:

<nothing>

Dokładnie ten sam program w naszym środowisku produkcyjnym z mysql 5.6 i nagłym potomkiem demona, który blokuje naprawdę ważne tabele i nigdy ich nie zwalnia.

From show full processlist:

28674638    dbuser  <app-prod>:54836    db  Sleep   67131   NULLInnodb 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

Gdy nie powoduje strasznych problemów, transakcja wygląda następująco:

---TRANSACTION 111578756, not started

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

Czy ktoś ma jakieś sugestie? Zastanawiam się trochę nad włączeniem trybu transakcji odczytu niezatwierdzonego, ale ... wydaje się, że jest to rozwiązanie innego problemu i naprawdę muszę wiedzieć, jaki jest oryginalny problem!