MYSQL 怎么发现处理没有commit 留下的“大”麻烦？

今天想说的是，习惯使用ORACLE 的程序员，在MYSQL 留下的麻烦怎么被发现。这两种数据库在处理事务上是有不同的，oracle 默认不会自动commit， 而mysql 会默认 auto commit， 说道auto commit ，四大数据库，只有oracle 一家是不默认commit。

那问题出在哪里，如果当初在程序员使用mysql 上设置了 auto commit 为非自动（线程级别，或global），而后期某些原因，又忘记了，记得MYSQL 本身是默认是 auto commit 那乱子就来了。所以一般都会看看developer 的历史，如果开发的历史用没有使用过mysql 则必然会多留心。

下面有一个例子，系统有一个更新一直过不去，一直报

Lock wait timeout exceeded; try restarting transaction

哪遇到这样的问题，会想起什么，怎么处理这个问题。 第一个想法是看看

show engine innodb stauts

看到上面的图，的反映是什么，有线程霸占某些记录的row lock 太长时间了，造成其他的session无法操作对应的记录。 在往深里面想，就有可能是没有commit 而造成的 session idel 而事务running 的问题。

遇到这样的问题，需要找出当前那个 session 正在idel 但其实里面的 transaction 在running 的状态。

1 找到正在sleep的session

2 查看耗时较长的session中运行的语句

通过查看到较长耗时的语句，以及语句的 processlist_id 就可以大致找到当前在作妖的线程ID。

然后kill他就好。

当然还有另外一种情况，就是程序里面由于不严谨，导致大批量的begin 但没有commit, 那这样用上面的方法就不赶趟了，怎么来更快的发现这样的问题

通过上图的语句，去发现相关的计数器是否一致在疯狂的上涨，那就证明当前的数据库系统中存在或可能存在这样的问题。