以前学过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
文档上自己说，不适合有大量文档的数据库，自增的不适合有大量文档的数据库