好久沒跟資料庫死磕了，這次是真被資料庫死磕了。
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們折騰去吧@#$@^%$