好久沒跟數據庫死磕了，這次是真被數據庫死磕了。
windows下沒有任何問題，移植到linux下，老區沒有任何異常情況，新區大量複製裝備，後臺工具運行期間，角色無法正常登陸，服務器顯示運行狀態良好。以前用得蠻好的工具，在新區數據庫才40萬數據帶索引一條update語句要1分鐘，而且update返回後，fetchdata操作終止，mysql返回2013(connetion lost)錯誤。
看到這些現象，當時我就吐槽了，mysql真的就是一坨渣。哥雖說算不上數據庫專家，起碼跟數據庫打了大半輩子交道算數據庫方向的老手了，這類奇葩的問題是第一次碰到，而且是百思不得其解。
經過週末兩天的長思，加上瀏覽各種網站對mysql的各種吐槽，我開始懷疑是mysql存儲引擎惹的禍了。
經多方查證，對MyISAM表的讀操作，不會阻塞其他用戶對同一表的讀請求，但會阻塞對同一表的寫請求；對 MyISAM表的寫操作，則會阻塞其他用戶對同一表的讀和寫操作；MyISAM表的讀操作與寫操作之間，以及寫操作之間是串行的。尼瑪，不支持併發，這還能叫數據庫嘛。
於是親手操刀大改，將工具中原來一邊read一邊update的操作改爲，一邊read一邊insert臨時表tmp，讀完之後update src from tmp。工具問題矇混過關，到此爲止，新區已經停服兩天並大量封號。
到此爲止，另外一個問題引起了我的注意，內網數據庫引擎都是InnoDB，爲啥跑新區變成MyIsam了?爲啥老區數據庫轉到linux沒出過問題，單新區各種連環問題？
於是show engines了一把，原來linux下mysql的默認存儲引擎爲MyIsam，而windows下Mysql的默認存儲引擎是InnoDB。
想通了這一點，所有的疑點到此終於迎刃而解。
MyIsam出於性能考慮不支持事務，讀和寫都是基於全表鎖定實現的，因而所有寫操作都會阻止別的寫操作和所有讀操作。因而後臺工具運行期間，全表掃描會阻止所有的存盤操作，大量複製裝備的現象可以解釋了。
工具表掃描期間對同一表讀寫互斥造成死鎖，update一直等到讀超時後完成操作，而此時，讀操作已經無法繼續。
perfect,多麼完美的解釋，淚奔中………………
發現問題永遠比解決問題困難100倍
以下是解決方案：
1.myIsam不支持併發(這種垃圾設計還會出現在現代數據庫引擎中，不噴你噴誰去)，需要將linux下默認存儲引擎改爲INNODB，windows下默認已經是InnoDB（通過sql語句 SHOW ENGINES; 可以查看當前默認存儲引擎）
[mysqld]
default-storage-engine=INNODB
2.修改現有myisam數據庫引擎爲innodb：
alter table tb engine=’innodb’;
不早了，洗洗睡吧，我什麼也不想說了。讓還在用MyIsam的2B們折騰去吧@#@^% ^%