The Finder, Spreadsheet Bridge and Schema Analyzer applications issue find queries based on your selections. When you have very large collections you might (intentionally or by mistake) issue queries that do not have supporting indexes in which case the query can run for a very long time. While you can always cancel a log-running operation if you have the right privileges, JSON Studio also includes a number of safeguards to ensure that you don’t have runaway queries.
The first safeguard is a visual cue that warns you when a query does not have supporting indexes. As you are building your query the “play” button with which you run the query becomes red if the query will run without indexes (note however that a totally empty query will not appear as red because the cursor will return data immediately and without loading the database). For example, the following two images show the Spreadsheet Bridge first with a query that has no index field and then with a query where an index field was added (the name).
Note that this visual warning only appears for collections of a certain size - controlled by a preference (the default is 500,000 but you can change that based on your hardware and requirements; a value of -1 means that no checks are made).
The second safeguard is prevention of queries that do not have the right supporting indexes. This is controlled by the prevention preference. When prevention is enabled, if you try to run the query (even after being warned) then the query will not run and instead you will get a warning as shown below.
The Schema Analyzer safeguards are simpler. There are two queries that you can perform that access the collections - distinct queries and type queries. Distinct queries in general are not very dangerous because their result sets are limited to 16M. Still, if you set the prevention preference, the distinct button will not even appear except for fields that have an associated index. Type queries always use cursors and limit the size of the result set to a maximum of 10,000 values.
NOTE: Both the visual cues and the prevention measures are not guaranteed. It is very hard to know when a combination of query and sort elements will be supported well by the indexes. Even the database itself needs to run the query in order to perform an explain and since we do not want to run the query (and risk the time), heuristics are used to warn you of potential costly queries. Use your judgment whether or not to run a warned query (i.e. whether to turn off prevention and run the query even if red). Also note that there is no index checks when using subqueries. In all cases using SonarResourceManager is highly recommended since then you can guarantee that queries will not consume more than allocated time.
MaxTimeMS - Coming in 1.4; after the release of MongoDB 2.6.