上线总是心惊胆战的，无论准备的多么充分，都无济于事，那种心惊胆战已经深入骨髓，昨天更是重新体会了一遍十八层地狱一日游。上线之前，我做了详细的准备，事先申请了数据库访问权限、建了表、加了数据、配置好配置文件，自认为能做的都做了，可是最后还是出现问题。

   1. 时间：5:10 PM

   事件：一切准备妥当，找运维上线，配置好配置文件，启动worker，结果：失败！！

   原因： 由于之前只考虑shell脚本的权限问题，却忘记了要软连接到固定的位置。

   解决方案：建立软连接。


   2. 时间：5:30 PM

   事件：建立软连接后兴致冲冲的重新上线，启动worker，结果：成功！！这个是很让人高兴的一件事情，但是查出来数据总量却是和我们预估的不太一样，是差太多，我们预估至少得有一千万数据，结果只有一百多万，我有点不大相信，去问dba，确认只有一百多万数据后，心中还是蛮高兴的，以后的业务处理会简单很多。

经验：在导数据之前一定要先确定数据的总数而不是自己推测、预估。


   3. 时间：5:50 PM

   事件： 开始导数据，启动worder，结果：失败！！这个是多么令人沮丧的事情啊。

   原因：由于监控系统打出的日志有一部分是乱码，大致推断是数据中有敏感字符，想去运维要日志，结果人家不给，理由是“太忙”。这就只能是自己推测原因了，最后死马当活马医，按有敏感字符处理。

   解决方案：改代码，打包，上线。

经验： 在导数据的时候要做最坏的打算，对数据进行敏感字符处理，以除后患。


   4. 时间：6:30 PM

   事件： 改完程序，重新启动worker，结果：失败！！我都快绝望了。

   原因：数据库字段长度不够，之前我们在设计数据库的时候考虑只是类似短消息的信息，内容不会太多，500字符足够，结果导致数据库字段长度不够，上线失败。

   解决方案：修改数据库字段类型，由以前的varchar（500）改为text，结果人家dba不给执行，因为没有提计划，最后求爷爷告奶奶，邮件抄送老大后，才勉强答应的（这里得感谢亲爱的dba同学了）。过一会，dba说“sql语句不行，公司现在不允许用大字段”，所以只能改varchar长度。一狠心500改成4000，dba同学给执行了。

经验：在设计数据库的时候充分的预估数据的容量，在允许的情况下设大一点比较好。


   5. 时间： 7:20 PM

   事件： 修改完数据库后，重新启动worker，结果成功！！我都快哭了，终于好了。


   6. 时间： 7:40 PM

   事件： 数据导完之后，接口平台切换到数据库，结果：成功！！我太高兴了，果然我写的代码宗师没什么问题的。


   7：时间：7:50 PM

   事件： 接口平台上线之后，事情并不是借此结束的，要线上验证。结果，日志系统不打日志，这个吓死我了，我还以为是程序出了问题呢。查看监控系统以后发现系统还活着，谢天谢地。过了五分钟后，日志系统重新开始打日志。好景不长，日志中出现error，好吧，最后还是出问题了。

   分析原因：由于之前调用别人接口的时候消息的主键是字符串类型，而我在数据库中存的是long类型，一些用户的页面上还是之前的主键，导致出现问题，这个应该只是偶然现象，万幸的是日志在打出35条error之后终于停了下来，我的心脏也慢慢停了下来。


   8：时间：8：20 PM

   事件：日志系统不再打出error，但是页面打开奇慢无比，

   原因：由于消息在打开页面时要将一部分的未读消息改成已读消息，但是天杀的我，竟然忘记了给主键加索引，页面打开竟然花了七秒以上，这绝对能进下周的big sql排行榜了。最后，加上索引，响应时间瞬时下来，有以前的1s表层1ms，好高兴啊！（好吧，这最后一句我骗人了，这是我今天早上来才加的，因为我这个只是消息总量访问得多，而页面访问频率太低，你们就尽情的鄙视我吧！）

   经验：索引、索引、一定要加索引，主键一定要加索引啊。