版本升级记录

12.12,4.0版本正式上线。

Boss要求：既要保留老版本（因为IOS客户端的开发有延迟，开发进度与Android相差太多），又要保留新版本的消息与老版本的相通，且联系人都要能在新老版本中相互关注。

好吧，保留，这还不简单，先转换用户基础数据，相关的业务数据，在用户升级到新版本的时候，同时做数据迁移。

满怀信心地，先在某宝做首发。用户登陆进来的速度和升级的速度还不错。嗯，测试都测过了，应该没有什么大问题。

好了，12,12晚上0.正式向所有android用户推送版本升级。

一开始，速度好快 ，2分钟后，客户端链接不上； 看日志，发现有事务在等待着处理，且有很多慢查询。好了，定位到了。接着要做修改了。

我发现我的模块，有个地方用到太多基础数据了，且这些查询的条件，都没有索引的。

于是，我想，单独创建一个表吧。好了，来了： 先建立表XXXX,   要数据嘛，快： 信手沾来： insert into XXXX select A ,B C from XXX.

嗯，数据量还是挺大了，建立了几分钟还没建立好。  等呗；

于是，大麻烦来了： 数据库报表被Lock了， 各种奔溃，用户都登陆不上，还波及到老版本的用户了。 一时间，用户骂声一遍又一遍。

技术经理，看了一下，在群里面说了： 所有使用到   insert into XXXX select A ,B C from XXX. 都全部停掉，因为这个会锁表。

看来，这下闹大了，好多转换的都使用到这个（当然是我（坏事者））。

好了，看来推送用户升级的要暂停一下了。

技术经理说： 明天大家都过来，加班，好好处理自己相应模块的转换。

......

早上，讨论了如何处理相关的转换：能往后迁移的，往后迁移，最好是由用户来触发迁移。

.......

因为不能使用insert into XXXX select A ,B C from XXX 只能 换另外一种方式了。

好了，只好先放弃效率，通过select 到一个对象，然后遍历对象，再一条一条插入数据库了。

一天时间过去了，哈哈大家的努力还是没有白费，

速度都上来了。数据转换上，还是会有个别用户的数据没有转过来，得一个一个处理了。

当然，数据库是mysql。

记录上线---->  哈哈，好兴奋的样子，虽然很困，但是看到自己的程序跑起来还是蛮高兴的。  看来，把BUG都调教的不错，哈哈哈哈哈哈。。。