如何“设置时间戳”是一个缓慢的查询吗？
我的慢速查询日志充满了如下条目：
# Query_time: 1.016361 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0
SET timestamp=1273826821;
COMMIT;
我猜 set timestamp 命令是由复制发出的，但我不明白 set timestamp 如何花费一秒多的时间。关于如何解决这个问题有什么想法吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Timestamp是MySQL中的一种数据类型和内置函数。您想通过以下声明达到什么目的？UPD：抱歉，我不知道所使用的MySQL hack。
似乎
SET TIMESTAMP用作 从慢速日志中排除某些查询的解决方案。OP正在使用Microslow补丁来增强慢查询日志中的统计信息，该语句在InnoDB表上的语句之前是常见的。
因此，OP问题的答案是
COMMIT语句是慢速查询，而不是SET TIMESTAMP。Timestampis a data type and a built-in function in MySQL. What are you trying to achive with the following statement?UPD: I am sorry, I didn't know about the used MySQL hacks.
It seems that
SET TIMESTAMPis 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
COMMITstatement is the slow query and not theSET TIMESTAMP.set timestamp 出现在每个慢查询日志中，所以跳过这一行； commit是慢查询中出现的原因；
由于如此多的提交进入慢速日志，因此数据库机器 IO 可能是问题所在，因为 IO 是提交的瓶颈。
监控DB CPU IO等待值，不能大于1/核心数。例如，如果是8核，IO等待应该小于12%。
iotop可以用来调试哪个进程正在读/写IO，iostat可以用来监控IO。
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.