一个update差点引发的血案

这算是前几天的事了，仅仅是在线上执行三个简单的update，由于大意差点引发血案，过程如下：

三条语句如下（因为保密原因表名都是处理过的测试表名)：

 UPDATE UCT_USER_ABC t,,UCT_UDC  t1 set t.USER_TYPE="TEACHER" where  t1.ID = t.USER_ID and  t1.USER_TYPE = 1;
 UPDATE UCT_USER_ABC t,UCT_UDC  t1 set t.USER_TYPE="PARENT" where   t1.ID = t.USER_ID and t1.USER_TYPE = 2;
 UPDATE UCT_USER_ABC t,UCT_UDC  t1 set t.USER_TYPE="STUDENT" where t1.ID = t.USER_ID and t1.USER_TYPE = 3;

然后在执行前随手看了一下前两条sql的执行计划如下：

sql1:

sql 2:

看执行计划都走了索引，扫描纪录虽然不少但因为是ssd盘，所以预估执行也很快差不多十几秒的样子，然后就开始了... ... 

首先设置非自动提交：

set autocommit=0然后执行前两个sql最后commit，事实证明确实很快，ok 一切顺利。

然后感觉第三条应该也差不多，故同样的方式执行第三条语句，发现很慢，并且发现大量慢查询！

感觉不对劲，立马中断执行，然后灰头土脸的赶紧看了一下第三条sql的执行计划如下：

差点没吐血而亡，居然是全表扫描，这下就理解了为啥那么多的阻塞，innodb不走索引的话就相当于表锁，导致更新和插入阻塞。

最后，等压力不大的时候偷偷摸摸的执行了一把足足4分多钟才执行完成。

ps: 作为一个dba，有时候真不要太相信直觉，细节之处才能见真性情。