公司RT系统某工单页面无法打开。通过httpwatch发现是图片附件比较大，卡住了页面加载最终导致。
询问当事人后，决定把图片删除掉。
右键菜单查看图片url，是http://rt.domain.com/Ticket/Attachment/123456/654321/12.jpg这样的格式~
于是在服务器的DocumentRoot下查找相关路径，发现Ticket/Attachment下只有一个文件dhandler，这是一段perl程序。
相关部分如下：
my $arg = $m->dhandler_arg; # get rest of path
if ($arg =~ '^(\d+)/(\d+)') {
$trans = $1;
$attach = $2;
}
my $AttachmentObj = new RT::Attachment($session{'CurrentUser'});
$AttachmentObj->Load($attach) || Abort("Attachment '$attach' could not be loaded");
unless ($AttachmentObj->id) {
Abort("Bad attachment id. Couldn't find attachment '$attach'\n");
}
unless ($AttachmentObj->TransactionId() == $trans ) {
Abort("Bad transaction number for attachment. $trans should be".$AttachmentObj->TransactionId() ."\n");
}
显然，该图片url对应的就是$trans=123456;$attach=654321。
再看RT/Attachment.pm，里面记录的是Attachments表的情况；再看其中的Create{}中相关部分如下：
perl
my $id = $self->SUPER::Create(
TransactionId => $args{'TransactionId'},
ContentType => $Attachment->mime_type,
ContentEncoding => $ContentEncoding,
Parent => $args{'Parent'},
Headers => $Attachment->head->as_string,
Subject => $Subject,
Content => $Body,
Filename => $Filename,
MessageId => $MessageId,
基本可以通过工单的id、url里的transactionid和Filename来唯一确定这个特大的图片了。
（实际这个Filename已经在transactionid生成的时候可以无视掉了，参见RT/Transaction_Overlay.pm里的Create{}。所以url里不管最后一段写什么*.jpg，结果都一样）
# mysql -uroot -p
> select * from rt3.Attachments where id='1234' and TransactionId='123456' and Filename='12.jpg';
然后屏幕开始哗哗的刷，全是-------
因为把图片内容存在Content字段里，显示就全是-了。
不过还是担心，万一这个-不是想象中的呢？
于是去找binlog。通过 strings binlog.* | awk '/12.jpg/ && /'$Date'/{print NR}' 找到当初create的记录（好在不是啥繁忙的系统，不然这种方法能被DBA鄙视死……），然后通过 awk 'NR>a && NR<b' 的方式查看create记录附件的其他内容。果然在Content字段，有几百行乱码，最开头就是JFIF，也就是jpg的图片格式。
最后 update rt3.Attachments set Content='' where id='1234' and TransactionId='123456' and Filename='12.jpg';删除这个超大图片，浏览页面就变快多啦~~
