最近開始研究MySQL和MongoDB，發現這方面資料不多。尤其是真正的說到點子上的文章，太少了。
有一些對比測試的文章基本上都是瞎測，測試方法都測到了馬腿上，得出的結論基本上都是NoSQL毫無價值
容我借用Russell Smith 的那句話：不是MongoDB不行，是你不懂。
讓我來分析一下MongoDB的真正性能吧。
有說MongoDB慢
反對：不設其他唯一索引的情況下，只用_id 在普通辦公電腦上每秒插入幾萬，在普通x86服務器上每秒插入十幾萬，你好意思說這個性能低？比mysql強出一個數量級。
贊同：檢索是真的慢，和sql數據庫不同，越複雜的條件搜索MangoDB越吃虧，CPU和IO的雙重壓力。面對那些直接把SQL查詢改寫成MangoDB的用法，別轉了，你不會收穫任何性能提升。
你不行：說你不行還是真的不行，MongoDB領導了NoSQL運動，NoSQL請注意，我們最主要反對的就是SQL的方法論，按SQL方法使用MangoDB你只能收穫失望。再想想MongoDB的設計思想：文檔化。_id 就是文件名，MongoDB是個文件系統。全文檢索？別鬧了，用文件名找文件，一個文件名對應一個文件，你絕對不會失望。
那麼MongoDB究竟應該怎麼用呢？
首先，忘記SQL
你應該忘記你學過的那些優雅無敵的SQL，不是說爲了提升檢索性能，扔索引就有好處。
有一個簡單的事實如下：只有一個默認的_id 索引，此時插入性能爲1，你再加一個索引，插入性能約1/2,再加一個約1/3 ,以此類推......
如果這個事實對你是很震撼的，那說明你還沒有忘記SQL，接着忘。
MongoDB的索引對插入性能有着不可忽略的拖後腿效應，所以，我們應該使用且僅使用 _id 作爲插入key，作爲查詢key，作爲所有的那個key。
其次，直接忘記搜索這件事。
把MongoDB當做你的硬盤，給他文件名去操作文件.這就是Key-Value數據庫的做法，你稍加設計就能這麼用。
那麼其實你所有的操作可以簡化爲兩個指令，邏輯上 就是一個字典
你給他_id,往字典裏插一個數據，或者拿一個數據。
Save({_id:xxx,.....})
FindOne({_id:xxx})
要想高性能，善用那個_id,把你原來準備當主鍵的那個玩意，hash成_id.
把你原來準備的查詢條件，什麼？查詢，拿_id來，別的全砍掉。
第三、這不是數據表
記住，這不是數據表，一個_id對應的東西不是一行數據，而是一個文件。
文件存儲和表存儲有什麼不同呢？
我舉個例子，比如我們要存儲用戶列表和每個用戶的道具列表。
數據表的做法是建一張用戶表，一張道具表，道具表裏有個字段表示他屬於哪個用戶。
然後，你就離不開萬惡的查詢了。
然後如果一個用戶有100條道具，100萬用戶意味着道具表有一億條記錄。
這時候就開始考驗你的小數據庫了，但這都是過去式了，這一億的道具，用MongoDB，根本不是個事兒
因爲MongoDB的方法是當做文件存，只設計一個用戶集合，每個用戶的信息是一個文件，然後這100個道具就分開存在每個用戶的文件裏。
然後來比較一下，我們取得用戶的記錄，然後從中拿出100個道具，NoSQL方法。
查一億的表，找出屬於某個用戶的記錄。
熟快熟慢？
然後你可能回想，SQL方法，我也可以搞個道具字段，把用戶的100個道具用某種協議打包，然後操作啊，一樣可以取得巨大的優化呀。
沒錯，你的想法很好，你正在用NOSQL的方式用SQL。
第四、文件存儲的精華之處
如果問題止於此處，MongoDB就毫無優勢可言了，如果這個方法在SQL數據庫上也是如此容易使用，那還費勁搞MongoDB幹什麼？
我們再折騰一點，如果每個道具還要存100條轉手記錄，你還是可以打包，但你這個打包字段已經1M了。
於是每次存取這個打包字段都是一個系統工程了，還要負擔1M的流量。
MongoDB這邊呢？我們可以直接對文件的一部分進行讀寫，比如我只返回一個用戶的第二個道具的信息，和返回第二個道具的第1~30條轉手記錄。
這，是一種怎樣的差距啊。
你想要一張美女的照片，你朋友有，但是他只有一個壓縮包，他那裏沒有解包工具，於是他把整個包傳給了你。他想問你要一張照片，但是他沒有壓縮工具，爲了存檔需要，他讓你再壓進包裏傳給他。
這個朋友就是你的用戶表的一行，如果換成真實世界的事件是多麼的不可思議，這就是在一個字段裏打包數據的問題。
MongoDB的一條記錄就是一個腦筋更正常的朋友，你要他一張照片，他從包裏找出來給你。你給他一張照片，他分門別類的放置到他的包裏去。
用文件的思維去訪問，MongoDB是一個更好的朋友。
審視一下你項目中的大部分的數據需求，是不是都可以用這種方式去組織呢？
如果是，加入NOSQL吧，我們的口號是：很暴力不SQL
還有什麼好處
1.不用邏輯關心的水平切分
無需多言，對MongoDB而言，這是運維人員的工作了
2.不用對齊的數據結構
不用對齊意味着你不用爲以前表結構變化的遷移煩惱，有些文件裏有一個部分，有些沒有，這對MongoDB而言，很正常。