mysql slow 日志的一个bug

今天看mysql slow日志的时候发现有些查询的时间特别长,如下面:

# User@Host: flowershop2[flowershop2] @  [10.176.202.139]
# Query_time: 18446744073709.550781  Lock_time: 0.000027 Rows_sent: 0  Rows_examined: 1
SET timestamp=1332464662;
UPDATE f_users SET uCash = ‘9861’, uSellFlowerTime = ‘1332464662’ WHERE uId = ‘1829711071’;
# Time: 120322 21:06:22
# User@Host: flowershop2[flowershop2] @  [10.176.227.212]
# Query_time: 18446744073709.550781  Lock_time: 0.000022 Rows_sent: 0  Rows_examined: 1
SET timestamp=1332464782;
UPDATE f_user_actions SET uaSize = ’11’ WHERE uId = ‘1551376611’ AND uaId = ‘1332129864763’;
# Time: 120322 21:07:22
# User@Host: flowershop2[flowershop2] @  [10.176.202.139]
# Query_time: 18446744073709.550781  Lock_time: 0.000020 Rows_sent: 2  Rows_examined: 2
SET timestamp=1332464842;

 

Query_time: 18446744073709.550781,显然这不是一个真实的查询时间。

网上搜了下,应该是mysql的一个bug, http://bugs.mysql.com/bug.php?id=47813 

不过这个bug 09年就有人报了,好像现在还没有fix掉.

看到一篇老外的文章分析说可能是多cpu造成的,如一个查询开如由一个cpu,后来又转到第二个cpu去执行时,就可能会产生这个问题。

老外的文章:http://www.mysqlperformanceblog.com/2009/05/17/what-time-18446744073709550000-means/