以前學過sql，現在在學mongodb。看到objectID各種想把它改成跟sql一樣從1開始auto increment的id，我就全給了update。聽說並不能這樣做，還是要保留mongo原有的自動產生的obectID， 但為什麼呢？
從原理上面分析一下其實很容易得到答案。假設你手上有一疊號碼，1到100，下面：
來了一個人問你要一個號，你給他一張，這沒問題。
兩個人一起到了，都問你要一個號，你怎麼辦？慢點一個個來啊，發完一張再發一張，慢一點但也將就
同時來了10個人問你要號怎麼辦，100個人呢？
把來了多少人想像成並發請求，不難發現很快分配號碼這點成了瓶頸。所以自增ID其實對RDBMS並不是好事呢。但好在傳統資料庫是單機的，無非就是自己給自己加個鎖在記憶體中處理競爭，問題不大。 MongoDB是個分散式資料庫，幾台機器要互相協調你拿1，我拿2，他拿3，這個鎖要透過網路協調，就很低效了。 想想分散式的目的，其中之一就是提高並發，所以自增ID和高並發其實是背道而馳的，在分散式環境中要確保正確遞增勢必要影響效率。再說自增ID除了看起來清爽點其實也沒有太大的優勢，所以必然就被放棄了。 （記住ObjectID其實也是可以排序的，就是插入時間順序）
https://docs.mongodb.com/v3.0/tutorial/create-an-auto-incrementing-field/#considerations
通常在 MongoDB 中，您不會對 _id 欄位或任何欄位使用自動增量模式，因為它無法針對具有大量文件的資料庫進行擴充。通常預設值 ObjectId 對於 _id 來說更理想。
文檔上自己說，不適合有大量文檔的資料庫，自增的不適合有大量文檔的資料庫
從原理上面分析一下其實很容易得到答案。假設你手上有一疊號碼，1到100，下面：
來了一個人問你要一個號，你給他一張，這沒問題。
兩個人一起到了，都問你要一個號，你怎麼辦？慢點一個個來啊，發完一張再發一張，慢一點但也將就
同時來了10個人問你要號怎麼辦，100個人呢？
把來了多少人想像成並發請求，不難發現很快分配號碼這點成了瓶頸。所以自增ID其實對RDBMS並不是好事呢。但好在傳統資料庫是單機的，無非就是自己給自己加個鎖在記憶體中處理競爭，問題不大。 MongoDB是個分散式資料庫，幾台機器要互相協調你拿1，我拿2，他拿3，這個鎖要透過網路協調，就很低效了。
想想分散式的目的，其中之一就是提高並發，所以自增ID和高並發其實是背道而馳的，在分散式環境中要確保正確遞增勢必要影響效率。再說自增ID除了看起來清爽點其實也沒有太大的優勢，所以必然就被放棄了。 （記住ObjectID其實也是可以排序的，就是插入時間順序）
https://docs.mongodb.com/v3.0/tutorial/create-an-auto-incrementing-field/#considerations
文檔上自己說，不適合有大量文檔的資料庫，自增的不適合有大量文檔的資料庫