Thanks for this hint. We also had this problem and never thought that the e-mail table caused it. Now everything runs fine!

Thanks, I already changed mantis_email_table->metadata/body from longtext to mediumtext.
After restart mysql, unfortunately it's still very slow when update/assign issue.
My enviroment: XAMPP+Mantis1.2.4

• Apache 2.2.17
• MySQL 5.5.8 (Community Server)
• PHP 5.3.5 (VC6 X86 32bit) + PEAR
• XAMPP Control Version 2.5 from www.nat32.com
• XAMPP Security
• phpMyAdmin 3.3.9

We're also having huge slowdowns when updating/assigning a bug to another user.
We've tested the proposed fix (changing tables) but it didn't change a thing.

• MySQL: 5.0.67 (5.0.67-0ubuntu6.1)
• Storage Engine: MyISAM
• Apache: 2.2.9 (Ubuntu)
• PHP: 5.2.6 (5.2.6-2ubuntu4.6 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g)

[UPDATE]
After we changed the "$g_phpMailer_method" variable in "config_local.php" things were up to speed again. We had it on 2 (external SMTP server) and when we changed it to 0 (mail()) and then back to 2 it was working at velocities multiple magnitudes higher than the speed of light.. well... it very fast once again.
But why it worked? It could be a slow DNS resolve (we have $g_smtp_host asigned a hostname) but that is speculation on our part.

Notes from Dylan:
"Wow, that’s a blast from the past! The changes I made fixed the huge slow-down I was seeing.

Perhaps on 64-bit machines a LONGTEST field is fast? All I know is that on our servers which were old P4s at the time using the field type absolutely destroyed performance, and as I mention in the notes that particular data type isn’t used in normal databases (at least that was the sentiment at the time I recall) because well, it’s overkill. 
It might also be simply a performance problem in MySQL 4.x and isn’t worth fixing now.

I tried all the other solutions suggested for speeding up the mailing (batching etc) and none of them were relevant to the problem I was having, although they do fix a lot of smaller speed problems. Basically the “huge speed down” I was seeing was Really slow, as in minutes to send a single mail. Perhaps there was disk-swapping going on or simply a bug in mySQL, I really don’t know, all I know is that switching the type sped it all back up again to sane speeds.

Also, I seem to recall that looking at the types of fields the XL type maps to for other database solutions showed a discrepancy. XL -> LONGTEXT simply seemed to be an incorrect over-sized mapping to me.
"

Marking as no change required - my email to dev list with current thoughts for if this comes up again, or we can reproduce below:

There are indeed reports on the internet of similar behaviour - e.g.
http://forums.mysql.com/read.php?10,378680,378795#msg-378795 . However, the reply I link to from Rick James (I think I recognise that name from being associated with mysql in some way or at least a helpful user)

Looking at

http://nicj.net/mysql-text-vs-varchar-performance/ and http://dev.mysql.com/doc/refman/5.7/en/internal-temporary-tables.html

If I were to hazard a guess, I'd probably be inclined to blame the use of 'order by' in some version of mysql.

Personally, I think I'm inclined to leave as is for now, and will close off this bug report. I'm inclined to modify email_queue_get_ids to always return ID's in the order of creation (we want emails to leave the mysql server in the order the notifications were generated - I'll submit a PR for this, so there's no need to ever do a reverse sort).

If we were to take a stab at avoiding a potential issue here, I'd be inclined to remove the ORDER BY clause completely, on the basis that the default expected state of the email table is to be empty at all times - when it's non-empty i.e. emails waiting to be processed, we always process all emails in one go assuming at working mail server. However, given the probability of a mail server breaking, and the fact that we want the ID's in order, and without the order by clause the order is undefined, I'm not going to remove the clause