上線總是心驚膽戰的，無論準備的多麼充分，都無濟於事，那種心驚膽戰已經深入骨髓，昨天更是重新體會了一遍十八層地獄一日遊。上線之前，我做了詳細的準備，事先申請了數據庫訪問權限、建了表、加了數據、配置好配置文件，自認爲能做的都做了，可是最後還是出現問題。
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，好高興啊！（好吧，這最後一句我騙人了，這是我今天早上來才加的，因爲我這個只是消息總量訪問得多，而頁面訪問頻率太低，你們就盡情的鄙視我吧！）
經驗：索引、索引、一定要加索引，主鍵一定要加索引啊。