三條語句如下（因為保密原因表名都是處理過的測試表名)：
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的執行計畫如下：
看執行計畫都走了索引，掃瞄紀錄雖然不少但因為是ssd盤，所以預估執行也很快差不多十幾秒的樣子，然後就開始了... ...
首先設定非自動提交：
set autocommit=0然後執行前兩個sql最後commit，事實證明確實很快，ok 一切順利。
然後感覺第三條應該也差不多，故同樣的方式執行第三條語句，發現很慢，並且發現大量慢查詢！
感覺不對勁，立馬中斷執行，然後灰頭土臉的趕緊看了一下第三條sql的執行計畫如下：
差點沒**而亡，居然是全表掃瞄，這下就理解了為啥那麼多的阻塞，innodb不走索引的話就相當於表鎖，導致更新和插入阻塞。
最後，等壓力不大的時候偷偷摸摸的執行了一把足足4分多鐘才執行完成。
ps: 作為乙個dba，有時候真不要太相信直覺，細節之處才能見真性情。
乙個memset引發的血案
前幾天做了一道bst題,提交了幾次都是wa,今天抽空拿了出來仔細瞧瞧總算被我發現禍頭根源.總結原因還在於自己對memset不太了解,以前用對估計也是瞎貓撞見死耗子 memset的介紹 void memset void buffer,int ch,size t count buffer 指向某段記憶體...
乙個分號引發的「血案」
再多的表情也無法詮釋我現在的心情！a b for matrices 這是很水的一道題，然而卻整整折騰了我2個多小時。從晚上6點多開始，花了沒幾分鐘就把 敲好了，可是資料一測，竟然不對，然後就開始找問題，找了很久，我竟然都還沒看出問題在哪，越找心裡越不爽，這麼做明明對的呀，一執行怎麼就錯了呢？一直到了...
乙個strlen引發的血案
部分測試 原來是這樣的 int decryptrelation aesdecryptfromfiletobytes const std string in file path,unsigned char out data,const char aes encrypt key,int in data ...