首先，測試環境上線新版本，並且通過黑盒測試以及功能測試。
然後，我們就上線了新的版本。
但是在執行3天後，整個伺服器大部分介面都失效了，基本上都是timeout。
檢查伺服器情況 cpu基本上佔滿了。
接著查了資料庫狀態，
通過mysql命令show processlist；存在大量的waiting for table flush狀態的sql語句。
其中找到了一條語句在analyze table的語句。
問題找到了 是這條語句很慢，而且同時的併發導致需要查詢這個表的執行緒狀態變為等待，因為mysql已經檢測到表資訊已經改變，
它需要關閉重新使用flush開啟此表.因此表將被鎖住，直到所有已經執行的查詢結束。
最後 直接殺掉了所有在執行的sql 就好了。
接下來，我們對執行的慢sql進行了優化 以及快取處理 就好了。
要重視慢查詢問題，有可能會引發災難性的後果。
記一次Innodb慢查詢分析過程
結論區分度低的索引到底會帶來哪方面的影響?資料量約700w create table order orderid varchar 32 not null comment 訂單編號 type char 1 default 0 comment 訂單型別 0 流量訂單,1 話費訂單 caller varc...
記一次伺服器事故
mysql資料庫報錯 can t create write to file tmp sql 6ccc 0.myi 在開始刪除之後，所有服務就已經恢復正常執行了，接下來就是優化那個session了，哎又是埋坑.最後附上inode擴容的方法 但是需要注意，手動擴inode，一般是新建分割槽時設定的，該操...
記一次git amend事故處理方案
問題是git commit amend 引起的。一條commit已經push到遠端develop了，但是後來又在這條commit上進行了amend操作，導致這條commit的雜湊碼發生了變化。並且後續又在這條commit之後進行了n條commit操作。大概的情況畫了個簡圖，如圖所示。下面的綠色就是最...