“查询结束”步骤在随机时间非常长

我正在基准测试一个Web应用程序，并且我的查询出现了大约1％的问题，主要是UPDATES（但有时也是INSERT）。我对这些请求进行了分析，似乎这是查询结束步骤花费了大量时间。“查询结束”步骤在随机时间非常长

starting 0.000029 
checking permissions 0.000005 
Opening tables 0.000017 
System lock 0.000005 
init 0.000032 
Updating 0.000052 
end 0.000030 
**query end 1.825892** 
closing tables 0.000025 
freeing items 0.000020 
logging slow query 0.000007 
logging slow query 0.000029 
cleaning up 0.000008

当我通过文件去

末：这发生在年底，但ALTER TABLE的清理之前，CREATE VIEW，DELETE，INSERT，SELECT，或UPDATE语句。

查询结束：此状态发生在处理查询之后但在释放项目状态之前。

那么这是否意味着我的更新清理需要时间？这一步究竟做了什么，我该如何提高性能？

感谢

来源

2011-08-04 Lliane

问题通过在/etc/my.cnf中

当多个线程想要写的文件在同一时间有一个联锁问题将

innodb_flush_log_at_trx_commit = 0

解决，这样日志会每秒刷新一次。

来源

2011-08-04 08:09:40 Lliane

非常感谢，有同样的问题。 – Frode

设置innodb_flush_log_at_trx_commit = 0不是轻易采用的解决方案，它从根本上改变了事务的持久性！ – 2012-12-11 16:12:50

同意。天真地设置innodb_flush_log_at_trx_commit可能是危险的，答案是误导。 –

“查询结束”步骤在随机时间非常长

回答

相关问题