DB引擎：InnoDB
兩表A，B表均為6W+的記錄。用B表的信息更新A表。
SQL：update A left join B on A.field1 = B.field1 and A.field2 = B.field2
set A.field3 = B.
field3, A.field4 = B.field4
無引擎時：每1000更新需要2分11秒，全部更新大概需要2~3小時。
此時加入索引：CREATE INDEX field1_Index ON `A`(`field1`);
注：1、此處只加field1是因為 field2的內容變化很小，就那幾個值。
2、此SQL里的字段都不是主鍵
再次執行SQL，效率依舊。似乎索引沒有作用。為了驗證我的想法，查看了執行方式：
explain update A left join B on A.field1 = B.field1 and A.field2 = B.field2 set A.field3 = B.field3, A.field4 = B.field4
果然在執行時，沒用到索引。找到癥結，那就繼續找為什么索引沒有被用的原因。
查找過程省略，直接上結果。
因為是update，所以我認為 左聯和直聯，對于結果沒有區別，但是從左聯改為直聯后，
再查詢執行方式，發現就能使用索引（原因暫不知道，以后知道了再寫）
于是再次執行如下SQL：
update A inner join B on A.field1 = B.field1 and A.field2 = B.field2 set A.field3 = B.field3, A.field4 = B.field4
6W+的數據執行時間：1.43秒
優化完畢。
另，因為以上字段都非主鍵，所以 SQL修改成以下方式執行似乎更快，查詢執行方式，用到了主鍵索引和我自己加的索引
update A left join B on A.field1 = B.field1 and A.field2 = B.field2
set A.field3 = B.field3, A.field4 = B.field4
where A.key in (select key from A)
附：
刪除索引：drop INDEX field1_Index ON `A`;
查看索引：show index from A
查看線程：select * from information_schema.processlist t
show processlist
殺線程： kill processId
COBOL的項目就要結束了,下個項目就是.NET.說實在話,我是比較期待,但是如果是C#,我就更加的HAPPY了,偏偏要是VB.NET,看了半天,發現怎么就那么的奇怪呢!就感覺看一段沒有斷句的文言文!還好,現在裝了個中文的MSDN,比以前看日文的MSDN要舒服多了,MD,看起來真費勁!
今天看VB.NET的代碼,突然有種感覺,就像剛到深圳去實習,看人家以前做的項目的代碼一樣,好費勁,很多的關鍵字,咋一看還不知道,稍一迷糊就看到后面,突然發現前面的幾句代碼是啥意思啊!不知道做的時候又是什么樣一種感覺,總的來說就是奇怪!ff
就要過年了,我卻離家太遠,不能回去過年,生平以來第一次不在家里過年,這是我出來工作的第一個年頭就在外鄉過!
真的好想回家,想念家里的父母,不知道他們身體是否還好!想念我那從小生活的地方,想回到我以前住過的房間睡上一晚!