这算是前几天的事了,仅仅是在线上执行三个简单的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,有时候真不要太相信直觉,细节之处才能见真性情。