I had a look at this issue. On my test database, the 2nd query runs in about 16-18 seconds on average, and its explain plan is as follows (non-relevant columns removed):

+------+-------------+------+-----------------+-------+---------------------------+-----+

|select|table        |type  |possible_keys    |key    |ref                        |rows |

+------+-------------+------+-----------------+-------+---------------------------+-----+

|SIMPLE|bug_table    |ALL   |status,project_id|NULL   |NULL                       |11132|

|SIMPLE|project_table|eq_ref|PRIMARY,id       |PRIMARY|mantis_bug_table.project_id|    1|

|SIMPLE|user_monitor |ref   |NULL             |PRIMARY|mantis_bug_table.id        | 7378|

+------+-------------+------+-----------------+-------+---------------------------+-----+

Analysis shows that the MySQL optimizer was not able to determine an appropriate key to use for joining mantis_bug_monitor_table and mantis_bug_table (possible_keys == NULL), and fell back on using the only available index for the joined table (key == PRIMARY) to match against the reference key, which is in fact a bug id (ref == mantis_bug_table.id).

The root cause for this, is that mantis_bug_monitor_table's PRIMARY (and only) index is [user_id, bug_id]. To achieve good performance here, we'd need to be able browse the table by bug_id too.

To prove my point, I added a new index as follows:

ALTER TABLE mantis_bug_monitor_table ADD INDEX bug_id ( bug_id );

With that, the explain plan becomes

+------+--------------------+------+-----------------+-------+---------------------------+-----+

|select|table               |type  |possible_keys    |key    |ref                        |rows |

+------+--------------------+------+-----------------+-------+---------------------------+-----+

|SIMPLE|mantis_bug_table    |ALL   |status,project_id|NULL   |NULL                       |11132|

|SIMPLE|mantis_project_table|eq_ref|PRIMARY,id       |PRIMARY|mantis_bug_table.project_id|    1|

|SIMPLE|user_monitor        |ref   |bug_id           |bug_id |mantis_bug_table.id        |    2|

+------+--------------------+------+-----------------+-------+---------------------------+-----+

So the good news is: fix is quite simple really (although some proper regression testing for adding this new index should be done).
The bad news: since the fix involves a schema change, we can't deploy it in 1.2...