首先該sql事務(wù)的where條件已經(jīng)命中了主鍵索引，而且表也不大，故可以排除掃表過慢原因。通過 show processlist;發(fā)現(xiàn)也只有該sql事務(wù)在操作這個(gè)表，初看起來似乎也不像是死鎖的原因：

　　但通過咨詢yellbehuang后發(fā)現(xiàn)，判斷sql事務(wù)是否死鎖不能簡單通過show processlist來判斷，而是要通過查詢innodb鎖的相關(guān)表來確定，和innodb鎖有關(guān)的主要有三個(gè)表，

　　上面表的各個(gè)字段的含義如下：

　　可以通過select * from INNODB_LOCKS a inner join INNODB_TRX b on a.lock_trx_id=b.trx_id and trx_mysql_thread_id=線程id 來獲取該sql的鎖狀態(tài)，線程id可以通過上面的show processlist來獲得，執(zhí)行結(jié)果如下：

　　此時(shí)發(fā)現(xiàn)，該sql連接確實(shí)處于LOCK WAIT鎖等待狀態(tài)

　　通過select * from innodb_lock_waits where requesting_trx_id=75CB26E5（即上面查詢得到的lock_trx_id）可以得到當(dāng)前擁有鎖的事務(wù)ID 75CB26AE。

　　再通過select * from innodb_trx where lock_trx_id=75CB26AE獲取sql語句與線程id

　　從上面的結(jié)果中看出，該事務(wù)處于running狀態(tài)，但sql卻為null，該線程id即對(duì)于上面show processlist的206機(jī)器的30764端口的連接，該連接處于sleep狀態(tài)。為什么sql為null卻依然占有鎖？在查詢相關(guān)資料和咨詢jameszhou后，知道了這個(gè)實(shí)際和innodb 引擎的寫機(jī)制有關(guān)，innodb執(zhí)行寫事務(wù)操作時(shí)，實(shí)際是先取得索引中該行的行鎖（即使該表上沒有任何索引，那么innodb會(huì)在后臺(tái)創(chuàng)建一個(gè)隱藏的聚集主鍵索引），再在緩存里寫入，最后事務(wù)commit后正式寫入DB中并釋放鎖。之所以sql為null，是因?yàn)樵撨B接已經(jīng)把sql update操作執(zhí)行寫入緩存中了，但是由于代碼bug沒有最后commit，導(dǎo)致一直占用著行鎖，后續(xù)新的連接想寫這一行數(shù)據(jù)卻因?yàn)橐恢比〔坏叫墟i而處于長時(shí)間的等待狀態(tài)。

　　那為什么innodb需要兩次寫？下面是我查詢相關(guān)資料得出來的結(jié)論：

　　因?yàn)閕nnodb中的日志是邏輯的，所謂邏輯就是比如當(dāng)插入一條記錄時(shí)，它可能會(huì)導(dǎo)致在某一個(gè)頁面（這條記錄最終被插入的位置）的多個(gè)偏移位置寫入某個(gè)長度的值，比如頁頭的記錄數(shù)，槽數(shù)，頁尾槽數(shù)據(jù)，頁中的記錄值等等，這些本是一些物理操作，而innodb為了節(jié)約日志量及其它一些原因，設(shè)計(jì)為邏輯處理的方式，那就是它會(huì)在一個(gè)頁面的基礎(chǔ)上，把一條記錄插入，那么在日志記錄中記錄的內(nèi)容為表空間號(hào)、頁面號(hào)、記錄的各個(gè)列的值等等，在內(nèi)部轉(zhuǎn)換為上面的物理操作。

　　但這里的一個(gè)問題是，如果那個(gè)頁面本身是錯(cuò)誤的，這種錯(cuò)誤有可能是因?yàn)閷憯嗔眩?個(gè)頁面為16K，分多次寫入，后面的有可能沒有寫成功，導(dǎo)致這個(gè)頁面不完整）引起的，那么這個(gè)邏輯操作就沒辦法完成了，因?yàn)樗那疤崾沁@個(gè)頁面還是正確的，完整的，因?yàn)槿绻@個(gè)頁面不正確的話，這個(gè)頁面里的數(shù)據(jù)是無效的，有可能產(chǎn)生各種不可預(yù)料的問題。

　　那么正是因?yàn)檫@個(gè)問題，所以必須要首先保證這個(gè)頁面是正確的，方法就是兩次寫，它的思想最終是一種備份思想，也就是一種鏡像。

　　innodb兩次寫的過程：

　　可以將兩次寫看作是在Innodb表空間內(nèi)部分配的一個(gè)短期的日志文件，這一日志文件包含100個(gè)數(shù)據(jù)頁。Innodb在寫出緩沖區(qū)中的數(shù)據(jù)頁時(shí)采用的是一次寫多個(gè)頁的方式，這樣多個(gè)頁就可以先順序?qū)懭氲絻纱螌懢彌_區(qū)并調(diào)用fsync（）保證這些數(shù)據(jù)被寫出到磁盤，然后數(shù)據(jù)頁才被定出到它們實(shí)際的存儲(chǔ)位置并再次調(diào)用fsync（）。故障恢復(fù)時(shí)Innodb檢查doublewrite緩沖區(qū)與數(shù)據(jù)頁原存儲(chǔ)位置的內(nèi)容，若數(shù)據(jù)頁在兩次寫緩沖區(qū)中處于不一致狀態(tài)將被簡單的丟棄，若在原存儲(chǔ)位置中不一致則從兩次寫緩沖區(qū)中還原。