分析 mnesia 索引慢的問題，結果出乎意料.
因爲 ejabberd 設計思路對 mnesia 做緩存情有獨鍾。
排除 cowboy 系統本身性能問題之後決定分析代碼。
前段時間對Cloud做壓力測試意外發現，當測試將要結束時，從出現socket斷開開始系統變得非常緩慢。甚至一個 http 請求相應也得花上1分多鐘，甚至更長，這顯然問題非常嚴重。對緩存性能之前做過測試，所以分析問題時直接跳過了。其實問題就是出現在緩存上。最終定位，當緩存數據達到5W條記錄後，性能急劇下降，特別是刪除數據和同樣重複寫入。每秒也就只能處理2k~3k 的樣子。這結果令人沮喪，這樣的性能怎能適合做緩存。
深深的回憶，之前測試和現在區別就是多了 index。難道 index 對性能影響如此之大。查了一下手冊，手冊上是這樣說的：
“Indices do not come free, they occupy space which is proportional to the size of the table. They also cause insertions into the table to execute slightly slower.
”
好吧，我相信了是索引造成的。
開始解決索引問題。差了好多資料有說慢的，可是沒有找到與我一樣的描述。因爲我沒有用 disc_copes。我全部用的 ram_copies. 羣裏諮詢也沒有看到很好的反饋，也得到了些幫助，在此感謝。
頭腦中產生了兩種想法。一是用 多表+transaction，二是純碎多表+no transaction.
趕緊寫代碼測試，transaction 在意料之中慢的很，還拋出一些錯誤。no transaction 不但沒有預期的快，還發寫數據和刪除現數據不完整。
分析了一下數據存儲形式，list 過程會導致性能降低（dict數據結構從思緒中閃過）。爲了解決多表no transaction數據不完整問題，把表的默認類型從 set 改爲 bag.這樣數據能準確的插入和刪除，不會出現覆蓋問題。測試沒問題。速度有所降低，但還能接受。數據不完整問題也解決了。想到此方法是否可以用到transaction 上面。
開始了 transaction+bag 測試。性能降低到同樣讓人絕望。想到用 transaction+bag +單表測試。結果發現 速度很快超出預期。一個個表添加依然很快。最後定爲到 ws_type 表上面去了。這樣一下子明白了。立刻切回 no transaction+index 去掉 type索引讀寫刪速度都非常之快50W條數據都在毫秒內完成，第一次寫總共花費 14121 ms，第二次重複寫 21423 ms,刪除數據 14777 ms，心情一下子晴朗了。接下來需要解決的就是 type 問題了。
無論用 index 還是 bag 類型，甚至分表K<->ValueList當 ValueList 超過2W 速度照樣拖慢。這纔是拖慢讀寫的本質。
<!--?xml version="1.0" encoding="UTF-8" standalone="no"?-->
Type 當前只有兩種類型 D和C。當有5W 條數據後。index、bag、另一張表（與 index 類似）速度通通慢的不行。