背景，隨著mongo資料量變大，查詢效率變低，要對索引進行優化，所在公司對mongo依賴比較嚴重，而dba並不對mongo的許可權做控制，所以每個後端開發都有mongo的讀寫許可權，通常每個人各自管理自己的模組的資料。
由於筆者所負責的模組資料增長較快，使用者的關鍵業務資料都存在mongo裡面，很快mongo裡面的資料就積累到幾百萬，之前只有乙個五個欄位的聯合索引，所以是時候作死了。。。
本著作死要有條不紊有依有據的原則，在測試資料庫接近百萬資料量的相同collection裡面進行了實操，阻塞方式加索引簡直快的飛起，shell裡面結果秒回，實際執行沒有監控，但也很快，因為幾秒內去測試介面，速度明顯提高，這樣折騰了幾回之後公司qa反映介面響應速度很快，頓時信心爆棚，要上線上大展拳腳。
乙個月後，要優化介面的任務下來了，頓時心花怒放，多日的準備終於要看到成果了：
一開始還是很謹慎的，試著加上乙個索引，當然時間選擇是下班前，這時候客戶大多下班，出了事情也能得到本公司運維的及時支援，照著測試環境的步驟，乙個乙個加，結果沒有任何使用者感知的情況下索引加成功！本著謹慎的原則，唯一乙個與測試環境操作不同的就是後台引數為true，天真的以為這樣就可以不影響服務了，正是這個不同導致了災難，事實上前幾個索引的新增確實沒什麼問題，十幾秒就新增成功，精神也逐漸鬆懈下來，這時，套用凱文哈特的一句話，it's about to go down!
加完了該加的索引後，去線上看看效果，結果並不理想，猜想原因是之前的5個鍵的聯合索引影響了查詢效率，於是想將其拆開，這樣雖然特定的乙個介面效率會有所降低，但是卻照顧了大多數的介面，於是刪除了這個索引，然後開始新建索引，過了一分鐘，還沒有返回結果，線上各種服務開始各種pending。。。事故發生，並持續了3個小時。
最終運維和dba查了各種資料在進行了一次mongo重啟後，在兩個多小時後，決定停服把原來的索引加回去，這時仍然是後台方式，不到5分鐘索引就增長了60%完成了建立，服務恢復。
總結：第一點，資料庫的索引操作一定在深夜進行，防止影響服務。第二點，看起來謹慎的後台建索引方式並不是最好的，資料量不大的情況下，阻塞可能更乾脆影響更小，在本案中，不到幾十秒肯定就能完成前台建立單鍵索引。最後，手裡有許可權不代表能操作，以後這種事一定要給dba做。
Mongo踩坑筆記
在我嘗試使用 home server mongodb bin mongod f home server mongodb conf mongodb.conf repair啟動時 報number 100異常 提示我not primary while creating collection admin.s...
後台踩坑筆記
code alau w6b yojdvc viuunk2f8te 7ztp2 tk url phone codevalue 原因 code中含有 等等符號 後台解析url時，會把code中的 識別為路徑中的分隔符，前後分別識別為key value 後台解析失敗，介面請求不成功 解決 encodeur...
Vmprotect 驅動加殼踩坑
1.慎用壓縮選項 當驅動有匯出函式時，需慎用壓縮選項。系統並不一定會呼叫模組的入口函式，導致沒解壓就訪問匯出函式。此時很大概率匯出函式所在位址不可訪問，或內容奇異。2.絕逼不要啟用comdat摺疊 該選項會將內容完全相同的函式就儲存乙份，一般情況下也不會出現內容完全相同的函式。但是當使用 try e...