前两天遇到一个1205(ER_LOCK_WAIT_TIMEOUT)的错误，弄了半天终于找到原因，掌握原理+细心才能找到罪归祸首。下面我给大家分享下这个问题的分析处理过程，希望对大家有所帮助。接到slave error告警后，看到现场是这样的：slave重做binlog因为锁超时中断，报HA_ERR_LOCK_WAIT_TIMEOUT错误。

     超时，easy啊，心想估计是有大事务长期持有锁，导致其他事务超时等待。但是这个库是只读的备库，不可能有写事务，通过show processlist命令也确实没有发现写事务，倒是有一个大查询任务。当时觉得MVCC查询不上锁啊，直接无视。我尝试重新start slave，发现没过几秒钟，错误依然出现，并且Exec_Master_Log_Pos没有变化，这说明同样的事务尝试写错误，依然被堵住，导致锁超时等待了。这一定是事务持有锁导致锁超时，但机器上除了查询，啥也木有。隔离级别，确认下隔离级别，虽然生产环境中机器都是RC(读提交)模式，但也不排除这种可能。但结果再次让我失望，事务隔离级别是读提交。



会不会是存储引擎的问题，我又验证了一把，表是innodb存储引擎，读不存在说是上表锁的情况。无语了，难道innodb的MVCC，读在某些情况下也上锁？这岂不是与读不上锁上违背吗？继续排查问题，查看锁等待情况：

这说明确实有事务堵住了更新。继续，

从图中可以看到，blocking_query确实是select语句，靠，难道真是它上锁了，上的什么锁呢？

可以看到一个读锁和一个写锁，这说明了，查询的确是上了记录的读锁，锁应该都是在innodb层面加的。到底为啥会上读锁呢？

     答案揭晓了，可以看到RUNNING的事务隔离级别是SERIALIZABLE，串行化隔离级别导致读上锁，进而阻塞复制无法进行下去。

     这个例子其实很简单，通过这个例子可以看到，information_schema下面的几张表太重要了，暴露了很多信息，方便我们排查问题。同时排查问题时，一定要坚信原理，并且细心，问题总会水落石出。