在mongoDB中，被选出的较优的执行计划，在后期的执行中如果不优了（如因为数据的变更或者查询传入参数的改变，没有达到预期的执行效率）怎么办？mongoDB自动感知到一个执行计划已经不优了的时候，将重新选择并缓存更优的执行计划。
mongoDB的这种不是基于cost和统计信息的优化选择器有一定的好处，但是也给数据库带来一定的负担。哪个好哪个不好确实不好定论。
使用CBO的数据库如PostgreSQL,在对数据表进行大批量操作后通常建议重新analyze该表(即收集统计信息)。Oracle也是如此，如果统计信息不正确将导致数据库选择较劣的执行计划给数据库带来严重负担。
而mongoDB没有统计信息当然也谈不上analyze,如果大批量更新数据导致执行计划不对的话按照mongoDB的说法应该下一次执行就会正常了。但是对于传入参数不一样导致的执行计划不对是不是会出现执行计划紊乱呢？解决办法除了重业务层隔离数据以外，使用非绑定变量也行。不过会给CPU带来严重负担。
【原文】
The MongoDB query optimizer generates query plans for each query submitted by a client. These plans are executed to return results. Thus, MongoDB supports ad hoc queries much like say, MySQL.
The database uses an interesting approach to query optimization though. Traditional approaches (which tend to be cost-based and statistical) are not used, as these approaches have a couple of problems.
First, the optimizer might consistently pick a bad query plan. For example, there might be correlations in the data of which the optimizer is unaware. In a situation like this, the developer might use a query hint.
Also with the traditional approach, query plans can change in production with negative results. No one thinks rolling out new code without testing is a good idea. Yet often in a production system a query plan can change as the statistics in the database change on the underlying data. The query plan in effect may be a plan that never was invoked in QA. If it is slower than it should be, the application could experience an outage.
The Mongo query optimizer is different. It is not cost based -- it does not model the cost of various queries. Instead, the optimizer simply tries different query plans and learn which ones work well. Of course, when the system tries a really bad plan, it may take an extremely long time to run. To solve this, when testing new plans, MongoDB executes multiple query plans in parallel. As soon as one finishes, it terminates the other executions, and the system has learned which plan is good. This works particularly well given the system is non-relational, which makes the space of possible query plans much smaller (as there are no joins).
Sometimes a plan which was working well can work poorly -- for example if the data in the database has changed, or if the parameter values to the query are different. In this case, if the query seems to be taking longer than usual, the database will once again run the query in parallel to try different plans.
This approach adds a little overhead, but has the advantage of being much better at worst-case performance.
