好久没跟数据库死磕了，这次是真被数据库死磕了。
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们折腾去吧@#@^%^%