How can "set timestamp" be a slow query?

My slow query log is full of entries like the following:

# Query_time: 1.016361  Lock_time: 0.000000 Rows_sent: 0  Rows_examined: 0
SET timestamp=1273826821;
COMMIT;

I guess the set timestamp command is issued by replication but I don't understand how set timestamp can take over a second. Any ideas of how to fix this?

Timestamp is a data type and a built-in function in MySQL. What are you trying to achive with the following statement?

SET timestamp=1273826821;

UPD: I am sorry, I didn't know about the used MySQL hacks.

It seems that SET TIMESTAMP is used as a solution to exclude some queries from the slow log.

The OP is using the Microslow patch to enhance stat info in the slow query log, and the statement is common before statements on InnoDB tables.

Thus, the answer to OP's question is that the COMMIT statement is the slow query and not the SET TIMESTAMP.

set timestamp appears in each slow query log, so skip this line; commit is the reason why it appears in slow query;

Since so many commit came into slow log, the db machine IO can be the problem, as IO is the bottleneck for committing.

Monitor DB CPU IO wait value, which can not be higher than 1/number of cores. For example, if 8 cores, IO wait should be less than 12%.

iotop can be used to debug which process is reading/writing IO, and iostat can be used to monitor IO.